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
Has any a good suggestion for a fpga program cable, which is known to work with linux (64 bits)? Thanks T.Article: 127351
Hello group, Anybody know if DAC plugin modules exist for the Xilinx ML505/ML506 board ? Thanks, JohnArticle: 127352
Why ask for expert help and refuse to try to see if the proferred answer solves the problem?Article: 127353
Which makefile should I use and where should the current working directory be located if I want to run a NIOS-II software build from the command line or emacs (linux or cygwin) rather than using Eclipse? Have anybodu used Emacs/GUD to interface to the NIOS-II gdb debugger? Thanks Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 127354
On 18 Dez., 20:07, kislo <kisl...@student.sdu.dk> wrote: > I am doing some initial research regarding PCB design process with a > Spartan3E (FT256) .. Have i understood it correctly that avnet are the > only distributor of xilinx FPGA=B4s ? .. in that case, i can order a > Spartan3E witch is not lead free .. and here comes the problem -> we > have vapor phase equipment to solder the BGA on the PCB. This vapor > phase machine uses liquid which reach 240degrees (Pb-free soldering), > will this damage the non-Pb-free FPGA? If it does, i have to convince > some ppl to buy some other liquid with lower vapor temperature :/ > > I have read the Device Package Userguide (ug112), regarding the Reflow > soldering process .. it dosent address the vapor phase process but i > guess its the same as for a normal oven process? .. is it critical to > obey the ramp temperature requirements? > > Regards > Kim there are several suppliers, not only avnet, so try push all of them to get pb-free versions vapor thing is almost the ONLY thing suitable for BGAs, so if you have that equipment be happy. for best results the correct temperature profile is sure required, but i guess your assembly department will know about that. you possible can use the pb-free profile for pb package too, at least for the development boards AnttiArticle: 127355
On 19 Dez., 13:10, Antti <Antti.Luk...@googlemail.com> wrote: > you possible can use the pb-free profile for pb package too, at least > for the development boards We had only 50% yield with that approach recently, albeit not with an FPGA. KoljaArticle: 127356
taco wrote: > Has any a good suggestion for a fpga program cable, which is known to work > with linux (64 bits)? > Thanks > T. let it be. I just ordered the xilinx usb cable.Article: 127357
On Dec 18, 9:46 pm, wxy0...@gmail.com wrote: > > Yes, see above and get rid of all of your processes that are clocked by > > 'CLKI_DIV' > > Thanks! > > But do you mean to let all logic clocked by CLKI, > meanwhile use CLKI_DIV as a clk_enable? Yes. > > That would make all the logic run at 300MHz. That's correct. > I want to use concurrent logic to achieve lower clock frequency, > that is why I am using CLKI_DIV. Some questions you should ponder then.... What is the point of the 300 MHz then? How low of a clock frequency are you trying to achieve? What is the reason for needing this lower clock frequency? The only real correct answer to all of the above is that you have some chunk of logic that needs to run at 300, and some other chunks that just can't because they fail timing. If that is not the situation, then use CLKI_DIV as a clock enable and be done with it. IF that is your situation, you should first consider breaking up the chunk-o-logic that doesn't run at 300 into smaller pipelined chunks that can. Finally, if you really do need the two clocks, then any communication between the CLKI and CLKI_DIV should be treated as if they are totally asynchronous clocks which generally means inserting fifos to move the data across the clock domains. > > Even if V4SX55 can run at 300MHz, > I don't think it's a good idea. > 1. Explain why you don't think it's a good idea. 2. Then explain why your design is attempting to run at least part of it at 300 MHz. 3. Then explain why your answer to #2 is not in violation of your answer to #1. > And I still have to worry about the skew of CLKI_DIV, > and the phase relationship beteen the 2 clocks, > which is the main problem. CLKI_DIV would no longer be a clock, you would not need to worry about the skew of CLKI_DIV and the phase relationship. Anyplace you previously were looking for a rising edge of CLKI_DIV (as a clock) you would replace with "if CLKI_DIV = '0'" as a clock enable as I demonstrated. If you had any code that was looking for falling edges of CLKI_DIV you would replace it with "if CLKI_DIV = '1'" (as a clock enable). > You know, if use BUFG to drive CLKI_DIV, > the phase relationship is hard to control, > If not, the skew will be a huge problem. > These 2 problems are all I got right now, > and they are still there! And the root cause of the problem is that you're using CLKI to generate CLKI_DIV which will inherently generate skew between these two signals. Even in simulation, they do not happen simultaneously, CLKI_DIV will happen on the next simulation delta. When they are both used as clocks you'll have the problems that you're seeing, if you use CLKI_DIV as a clock enable as Symon and I have pointed out you won't. If you want to beat your head against the wall trying to solve this go ahead but all you'll get is a headache and a flaky design that will mysteriously work (or not) when you first power it on, then will not work (or work) once it has been powered up for some period of time....which you'll attribute to some mysterious temperature sensitivity....but the reason for the 'sensitivity' is improper design and failing timing analysis which is what your timing report is telling you right now. > > I really wanna know your solution in detail. What detail do you think was not disclosed previously? Kevin JenningsArticle: 127358
On Tue, 18 Dec 2007 18:46:38 -0800 (PST), wxy0624@gmail.com wrote: >> Yes, see above and get rid of all of your processes that are clocked by >> 'CLKI_DIV' > > >Thanks! > >But do you mean to let all logic clocked by CLKI, >meanwhile use CLKI_DIV as a clk_enable? > >That would make all the logic run at 300MHz. Exactly. >I want to use concurrent logic to achieve lower clock frequency, >that is why I am using CLKI_DIV. But why? > And I still have to worry about the skew of CLKI_DIV, > and the phase relationship beteen the 2 clocks, >which is the main problem. No - you let the tools worry about them. If the tools can achieve timings WITHOUT issuing warnings, there is no worrying to be done. This approach lets the timing constraints necessary on the 150MHz clock to be correctly inferred by the tools. And there are no clock domain crossings to worry about. - BrianArticle: 127359
hi i'm using edk 9.1 and i have to write my own ip core. i want to use the ppc405 in a virtex 4 an was wondering if that supports the fsl link. in the datasheet for the fsl link it only talks about the microblaze processor... can i expect to work the fsl link also with the ppc? should i expect any difficulties? thanks urbanArticle: 127360
On Dec 19, 7:20 am, Brian Drummond <brian_drumm...@btconnect.com> wrote: > On Tue, 18 Dec 2007 18:46:38 -0800 (PST), wxy0...@gmail.com wrote: > >> Yes, see above and get rid of all of your processes that are clocked by > >> 'CLKI_DIV' > > >Thanks! > > >But do you mean to let all logic clocked by CLKI, > >meanwhile use CLKI_DIV as a clk_enable? > > >That would make all the logic run at 300MHz. > > Exactly. > > >I want to use concurrent logic to achieve lower clock frequency, > >that is why I am using CLKI_DIV. > > But why? > > > And I still have to worry about the skew of CLKI_DIV, > > and the phase relationship beteen the 2 clocks, > >which is the main problem. > > No - you let the tools worry about them. If the tools can > achieve timings WITHOUT issuing warnings, there is no worrying to be > done. > > This approach lets the timing constraints necessary on the 150MHz clock > to be correctly inferred by the tools. And there are no clock domain > crossings to worry about. > > - Brian Another approach might be to generate the 150 MHz clock with a BUFGE, enabled by clki_div (keep in mind that such a clock may not be 50% duty cycle). Or use a DCM. Otherwise, you have been given the best advice, and only if you really need the rest of your design to run at 150 (for power savings, etc?) should you actually generate a slower clock signal, and then there are good ways to do it (what I suggested above) and bad ways (what you were doing). If your logic that you want to run at 150 MHz is too complex to run at 300, then you can use a 150 MHz clock enable as suggested previously, with multi-cycle path constraints to relax timing on those paths that have two 300 MHz cycles to complete. However, this is generally more error prone, since incorrectly specified multi-cycle paths can usually only be found by a simulation that exercises the incorrectly specified path. As to the difference between lab operation and simulation warnings, even if you were to test with your voltage at the lowest possible value, and raise the temperature to the highest, consider that your lab experiment works on a sample of one FPGA, from one production lot. If you plan on producing more than just the board you have in the lab, you need to solve the problems indicated by the simulator and/or timing analysis tool. "Works in the lab" is necessary, but not sufficient for "works in production". AndyArticle: 127361
austin wrote: > Larry, > > The FPGA is not a battery. If there is that high a voltage on > unconnected banks, well, they are obviously connected to something, > aren't they? > > It could be that you have a 5V CMOS driver driving an input in that > (those) bank(s), which causes the upper protection diode(s) to be > forward biased. > > The voltages you have reported are greater than the abs max in the data > sheet, so you risk blowing out the gates/junctions on the IO transistors > in those banks -- DON'T DO THAT! > > Austin Austin, Yes, you saw the correct trouble : FORWARD BIASE. But how? An pin on a connector can output io signal coming from Bank1 or can drive a regulated 5V. The selection of these two output are done with a analog FET switch. BUT, the pull-down resistor setting the Switch was 470k instead the 4k7 ;-)... Before the configuration of the FPGA, the 5V was coming on one io of bank1 then via the protection diode the 5V comes on all the VCCIO of bank1 and Bank3... Note: after configuration of the SP3 all comes correct since the FPGA drives the analog switch :-) The Spartan3E was stressed, but still working ! Thank you Austin. Regards, LarryArticle: 127362
On Dec 19, 8:22 am, "u_stad...@yahoo.de" <u_stad...@yahoo.de> wrote: > hi > > i'm using edk 9.1 and i have to write my own ip core. i want to use > the ppc405 in a virtex 4 an was wondering if that supports the fsl > link. in the datasheet for the fsl link it only talks about the > microblaze processor... > can i expect to work the fsl link also with the ppc? > should i expect any difficulties? > > thanks > urban Yes it does. Look at the fcb2fsl_bridge pcore. You can find it in the EDK GUI at: Project Information Area -> IP Catalog -> Bus_Bridge -> fcb2fsl_bridge. Regards, John McCaskill www.fastertechnology.comArticle: 127363
On 19 Dez., 13:24, "comp.arch.fpga" <ksuli...@googlemail.com> wrote: > On 19 Dez., 13:10, Antti <Antti.Luk...@googlemail.com> wrote: > > > you possible can use the pb-free profile for pb package too, at least > > for the development boards > > We had only 50% yield with that approach recently, albeit not with an > FPGA. > > Kolja Hi, if need prototypes quickly the 50% is fully acceptable, thats why i suggested i guess there actual yield depends on many factors as the package type and moisture, etc.. AnttiArticle: 127364
On Wed, 19 Dec 2007 04:47:56 -0800 (PST), KJ <Kevin.Jennings@unisys.com> wrote: >Finally, if you really do need the two clocks, then any communication >between the CLKI and CLKI_DIV should be treated as if they are totally >asynchronous clocks which generally means inserting fifos to move the >data across the clock domains. I don't think in general this makes sense; depending on the capabilities of the STA tool, the way timing is checked starts at a main pin and traces it through the clock buffers/delays for both source and the target flops to calculate the clock arrival times. The fact that a clock divider in one of the paths doesn't make the divided clock asynchronous and the result is no less dependable then when all the delays are just clock buffers/inverters. There is just one clock->Q delay instead of a buffer and a good STA tool should be account for that.Article: 127365
On Dec 19, 12:14 pm, mk <kal*@dspia.*comdelete> wrote: > On Wed, 19 Dec 2007 04:47:56 -0800 (PST), KJ > > <Kevin.Jenni...@unisys.com> wrote: > >Finally, if you really do need the two clocks, then any communication > >between the CLKI and CLKI_DIV should be treated as if they are totally > >asynchronous clocks which generally means inserting fifos to move the > >data across the clock domains. > > I don't think in general this makes sense; depending on the > capabilities of the STA tool, the way timing is checked starts at a > main pin and traces it through the clock buffers/delays for both > source and the target flops to calculate the clock arrival times. The > fact that a clock divider in one of the paths doesn't make the divided > clock asynchronous and the result is no less dependable then when all > the delays are just clock buffers/inverters. I don't disagree about how STA computes paths, but what I said was "...the CLKI and CLKI_DIV should be treated as if they are totally asynchronous clocks". By that what I meant, was that one should approach the design *as if* the two clocks are unrelated and use proper clock domain crossing design techniques. That will lead to a robust design. Trying to constrain your way to happiness generally results in 'brittle' designs where simple changes cause timing paths to now fail and lead to another round of new constraints, random number seeds, etc. because the synthesis tool was slightly off when it was estimating delays when it used those constraints to try to optomize timing during the mapping/fitting/routing process. >There is just one > clock->Q delay instead of a buffer and a good STA tool should be > account for that. And the OP's static timing analysis already is catching the problem....the fact that he's not following good FPGA design practice is causing him to try to stomp out the problem with constraints that will keep biting until he changes the functional description of his design. KJArticle: 127366
On Dec 18, 5:29 pm, Brian Davis <brimda...@aol.com> wrote: > John_H wrote: > > > What's the best way to clock DDR flops from a DCM? > > In V2, the two clock net scheme works best. > > When doing this, I've avoided the DCM jitter by running > the clock into a DIFF_OUT global buffer variant without > using a DCM. > > I haven't measured this in S3E. > > > > > Much of the early DDR information suggested using the 0 and 180 degree > > outputs from the DCM. I never considered this a good design practice > > because the outputs are going through different BUFGs with different > > clock loads on each net resulting in a designed-in skew that would > > compromise the DDR sampling windows. > > I've used isolated clock nets for just the DDR I/O, with a different > net for the global logic clock, in my past V2 designs; this requires > intentional LOCing of the global buffers to the clock sites having > shared routing resources. > > I posted about this a while back on the "DIFF_OUT Buffer Example" > thread, see this thread and the comments in the code example: > > http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/367ad... > > > > > Is there any real evidence one way or the other to suggest that one of > > these approaches is better than the other? > > I measured V2 clock duty cycle and DDR setup/hold, without > any DCM involvement, by using a two channel HP8133A and > forwarding the clock and DDR data output back out another > LVDS pair to a 20 GHz sampler. > > > > > Don't newer parts route differential clocks for single global clock > > nets now? Or is that just the Virtex series? My designs are > > V4 and V5 have differential global routes, but in V4 some of the > regional resources are still single ended ( and because V4 can't > directly clock a global spline from a local clock input having the > best DDR I/O performance, some creative clocking workarounds are > required to avoid needing the same clock on a global & local input) > > Brian Thanks for the discussion and the link to the previous thread. I have the unfortunate need of using the DCMs to multiply the incoming clock so I lose margin from the start. In the other thread you mentioned the DCM does 50% duty cycle correction - as I've known - but the XAPPs *appear* to suggest that 50% duty cycle correction happens local to the DCM - not at the global buffer feedback level - such that duty cycle distortion in the global clock is still an issue. Joy. I really don't enjoy the idea of 3 global clocks to get the matched 0/180 clocks for the IOBs and the logic clock, but if it gains another 300 ps in margin, perhaps it's worth rearranging things. I appreciate that I'm not the only one who sees the clock loading difference as a root issue that needs to be addressed. Maybe XAPP485 didn't have it terribly wrong using the CLKFX and ~CLKFX as the inputs to the two clock buffer (that I saw as a bastardization of the 2 approaches). If the 50% duty cycle correction is local to the DCM and not the global clock, this inversion would work. If the 50% duty cycle correction is global, however, the global clock polarity that isn't part of the feedback path would be that much worse off. I have yet to find an app note or white paper that really addresses the global 50% issue. I'll look deeper into DCM literature and perhaps try some 3-clock receive timing analysis to see how/if the numbers differ. Thanks, - John_HArticle: 127367
On Dec 18, 6:46 pm, wxy0...@gmail.com wrote: > > Yes, see above and get rid of all of your processes that are clocked by > > 'CLKI_DIV' > > Thanks! > > But do you mean to let all logic clocked by CLKI, > meanwhile use CLKI_DIV as a clk_enable? > > That would make all the logic run at 300MHz. > I want to use concurrent logic to achieve lower clock frequency, > that is why I am using CLKI_DIV. > > Even if V4SX55 can run at 300MHz, > I don't think it's a good idea. > > And I still have to worry about the skew of CLKI_DIV, > and the phase relationship beteen the 2 clocks, > which is the main problem. > You know, if use BUFG to drive CLKI_DIV, > the phase relationship is hard to control, > If not, the skew will be a huge problem. > These 2 problems are all I got right now, > and they are still there! > > I really wanna know your solution in detail. Sorry I'm late to the thread... The main point I haven't seen communicated is that the clock-enabled logic will, indeed, be running with a 300 MHz clock, but... ...you can specify a multi-cycle path for all the registers fed by the clock enable to two 300 MHz clock cycles. The place&route and timing analysis will make sure the single-cycle 300 MHz logic works at 300 MHz as you need. The clock enable that needs to reach the enabled flops within a 300 MHz period will be routed properly. The logic that wants to run slower, however, requires only the lazy two cycles worth of delay to get the proper results; the uncertain results when the clock is not enabled will not affect your results. As long as the multi-cycle constraint is properly applied, this all- synchronous approach works even better than pipelining the logic to be all 300 MHz. Multi-cycle constraints and one high speed clock will solve many of your troubles. - John_HArticle: 127368
"John_H" <newsgroup@johnhandwork.com> wrote in message news:032b97a2-abf3-48c6-8039-af436b23f2f5@y5g2000hsf.googlegroups.com... > On Dec 18, 5:29 pm, Brian Davis <brimda...@aol.com> wrote: >> John_H wrote: >> >> > What's the best way to clock DDR flops from a DCM? >> >> In V2, the two clock net scheme works best. >> >> When doing this, I've avoided the DCM jitter by running >> the clock into a DIFF_OUT global buffer variant without >> using a DCM. >> >> I haven't measured this in S3E. >> >> >> >> > Much of the early DDR information suggested using the 0 and 180 degree >> > outputs from the DCM. I never considered this a good design practice >> > because the outputs are going through different BUFGs with different >> > clock loads on each net resulting in a designed-in skew that would >> > compromise the DDR sampling windows. >> >> I've used isolated clock nets for just the DDR I/O, with a different >> net for the global logic clock, in my past V2 designs; this requires >> intentional LOCing of the global buffers to the clock sites having >> shared routing resources. >> >> I posted about this a while back on the "DIFF_OUT Buffer Example" >> thread, see this thread and the comments in the code example: >> >> http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/367ad... >> >> >> >> > Is there any real evidence one way or the other to suggest that one of >> > these approaches is better than the other? >> >> I measured V2 clock duty cycle and DDR setup/hold, without >> any DCM involvement, by using a two channel HP8133A and >> forwarding the clock and DDR data output back out another >> LVDS pair to a 20 GHz sampler. >> >> >> >> > Don't newer parts route differential clocks for single global clock >> > nets now? Or is that just the Virtex series? My designs are >> >> V4 and V5 have differential global routes, but in V4 some of the >> regional resources are still single ended ( and because V4 can't >> directly clock a global spline from a local clock input having the >> best DDR I/O performance, some creative clocking workarounds are >> required to avoid needing the same clock on a global & local input) >> >> Brian > > Thanks for the discussion and the link to the previous thread. > > I have the unfortunate need of using the DCMs to multiply the incoming > clock so I lose margin from the start. In the other thread you > mentioned the DCM does 50% duty cycle correction - as I've known - but > the XAPPs *appear* to suggest that 50% duty cycle correction happens > local to the DCM - not at the global buffer feedback level - such that > duty cycle distortion in the global clock is still an issue. Joy. > > I really don't enjoy the idea of 3 global clocks to get the matched > 0/180 clocks for the IOBs and the logic clock, but if it gains another > 300 ps in margin, perhaps it's worth rearranging things. I appreciate > that I'm not the only one who sees the clock loading difference as a > root issue that needs to be addressed. > > Maybe XAPP485 didn't have it terribly wrong using the CLKFX and ~CLKFX > as the inputs to the two clock buffer (that I saw as a bastardization > of the 2 approaches). If the 50% duty cycle correction is local to > the DCM and not the global clock, this inversion would work. If the > 50% duty cycle correction is global, however, the global clock > polarity that isn't part of the feedback path would be that much worse > off. > > I have yet to find an app note or white paper that really addresses > the global 50% issue. I'll look deeper into DCM literature and > perhaps try some 3-clock receive timing analysis to see how/if the > numbers differ. > > Thanks, > - John_H The real issue about duty cycle distortion, in DDR interfaces, is how it affects setup/hold time. Doesn't the use of the (jittery) CLKFX outputs have a much bigger effect on setup/hold time? BobArticle: 127369
Hi all, I used to work with Xilinx ISE, there you could compile the unisim, simprim libraries. I have switched from Xilinx to Altera where I would like to with the same ease compile Altera specific libraries. But I have not found a similar way. Is there such a script or do I need to do it manualy? Regards, /RNArticle: 127370
kislo wrote:
> I am doing some initial research regarding PCB design process with a
> Spartan3E (FT256) .. Have i understood it correctly that avnet are the
> only distributor of xilinx FPGA´s ? .. in that case, i can order a
> Spartan3E witch is not lead free .. and here comes the problem -> we
> have vapor phase equipment to solder the BGA on the PCB. This vapor
> phase machine uses liquid which reach 240degrees (Pb-free soldering),
> will this damage the non-Pb-free FPGA? If it does, i have to convince
> some ppl to buy some other liquid with lower vapor temperature :/
>
> I have read the Device Package Userguide (ug112), regarding the Reflow
> soldering process .. it dosent address the vapor phase process but i
> guess its the same as for a normal oven process? .. is it critical to
> obey the ramp temperature requirements?
>
The original premise behind this question is incorrect.
1) Avnet is only one of several distributors that sell Xilinx parts.
Your posting address indicates that you are located in Denmark and
Silica (an Avnet company) is the only local distributor. Nu Horizons
has offices in Germany and the UK.
2) The Spartan-3E family is available in both lead and PB-free
packages. Simply order the FTG256 (instead of the FT256) to get
the PB-free package version.
Ed McGettigan
--
Xilinx Inc.
Article: 127371On Wed, 19 Dec 2007 09:51:28 -0800 (PST), KJ <Kevin.Jennings@unisys.com> wrote: >On Dec 19, 12:14 pm, mk <kal*@dspia.*comdelete> wrote: >> On Wed, 19 Dec 2007 04:47:56 -0800 (PST), KJ >> >> <Kevin.Jenni...@unisys.com> wrote: >> >Finally, if you really do need the two clocks, then any communication >> >between the CLKI and CLKI_DIV should be treated as if they are totally >> >asynchronous clocks which generally means inserting fifos to move the >> >data across the clock domains. >> >> I don't think in general this makes sense; depending on the >> capabilities of the STA tool, the way timing is checked starts at a >> main pin and traces it through the clock buffers/delays for both >> source and the target flops to calculate the clock arrival times. The >> fact that a clock divider in one of the paths doesn't make the divided >> clock asynchronous and the result is no less dependable then when all >> the delays are just clock buffers/inverters. > >I don't disagree about how STA computes paths, but what I said was >"...the CLKI and CLKI_DIV should be treated as if they are totally >asynchronous clocks". By that what I meant, was that one should >approach the design *as if* the two clocks are unrelated and use >proper clock domain crossing design techniques. That will lead to a >robust design. I think my problem is with the sections "should be treated ..." and "a robust design" which to me sounds like if they're not, the result will not be a robust design with which I disagree. Also forcing a design to run at 2X MHz speed will push the synthesis a lot more than running it at X. If one pays some attention to the first 2X->X boundary (ie minimal or no logic in between), the STA will correctly manage the clock tree and there will be no problems. This way the design will be at least as robust as treating them async and putting in async fifos which are quite complicated to design too.Article: 127372
On Dec 19, 10:08 am, "BobW" <nimby_NEEDS...@roadrunner.com> wrote: > > The real issue about duty cycle distortion, in DDR interfaces, is how it > affects setup/hold time. Doesn't the use of the (jittery) CLKFX outputs have > a much bigger effect on setup/hold time? > > Bob The jitter is miserable for high speed DDR interfaces. But when the clock frequency comes in at 1/7th the bit rate and there's no PLLs in the Spartan3E, the DCMs are a necessary evil. I just want to make the DCM jitter the *only* remaining loss to the design margins that I can twiddle with. - John_HArticle: 127373
On Dec 19, 10:43 am, mk <kal*@dspia.*comdelete> wrote: > > I think my problem is with the sections "should be treated ..." and "a > robust design" which to me sounds like if they're not, the result will > not be a robust design with which I disagree. Also forcing a design to > run at 2X MHz speed will push the synthesis a lot more than running it > at X. If one pays some attention to the first 2X->X boundary (ie > minimal or no logic in between), the STA will correctly manage the > clock tree and there will be no problems. > This way the design will be at least as robust as treating them async > and putting in async fifos which are quite complicated to design too If the synthesis uses multi-cycle constraints, the synthesis will not be pushed. The synthesis will make sure the combinatorial paths conform to the needs of the multi-cycle path's period.Article: 127374
On Dec 19, 1:43 pm, mk <kal*@dspia.*comdelete> wrote: > On Wed, 19 Dec 2007 09:51:28 -0800 (PST), KJ > > > > > > <Kevin.Jenni...@unisys.com> wrote: > >On Dec 19, 12:14 pm, mk <kal*@dspia.*comdelete> wrote: > >> On Wed, 19 Dec 2007 04:47:56 -0800 (PST), KJ > > >> <Kevin.Jenni...@unisys.com> wrote: > >> >Finally, if you really do need the two clocks, then any communication > >> >between the CLKI and CLKI_DIV should be treated as if they are totally > >> >asynchronous clocks which generally means inserting fifos to move the > >> >data across the clock domains. > > >> I don't think in general this makes sense; depending on the > >> capabilities of the STA tool, the way timing is checked starts at a > >> main pin and traces it through the clock buffers/delays for both > >> source and the target flops to calculate the clock arrival times. The > >> fact that a clock divider in one of the paths doesn't make the divided > >> clock asynchronous and the result is no less dependable then when all > >> the delays are just clock buffers/inverters. > > >I don't disagree about how STA computes paths, but what I said was > >"...the CLKI and CLKI_DIV should be treated as if they are totally > >asynchronous clocks". By that what I meant, was that one should > >approach the design *as if* the two clocks are unrelated and use > >proper clock domain crossing design techniques. That will lead to a > >robust design. > > I think my problem is with the sections "should be treated ..." and "a > robust design" which to me sounds like if they're not, the result will > not be a robust design with which I disagree. OK, we agree to disagree then. > Also forcing a design to > run at 2X MHz speed will push the synthesis a lot more than running it > at X. Pipelining or specifying multi-cycle paths addresses that concern. > If one pays some attention to the first 2X->X boundary (ie > minimal or no logic in between), the STA will correctly manage the > clock tree and there will be no problems. If generally true, then the OP wouldn't be having the setup problem now would he? The reason he is having this warning is because of the inherent skew between the clock to a flip flop and the output of that flip flop and using them both as clocks which can not be 'managed' no matter how much attention you pay. This is a clock domain crossing problem, and while the frequency of the two clocks have a nominal relationship to each other (i.e. one is 2x the other) there is NO controllable relationship between the skew of the edges of these clocks and THAT is what is causing the timing 'warning' and eventually a real failure. > This way the design will be at least as robust as treating them async > and putting in async fifos which are quite complicated to design too.- Hide quoted text - > Well, I certainly wouldn't bother to write the code to implement an async FIFOs. I would write code that the synthesis tool would infer to be whatever hard macro that the device inherently has....could be as simple as using the 'lpm_fifo_dc' (or using Mr. Wizard if one so chooses). The silicon guys are the ones that can properly implement the async fifo, the FPGA designer needs to write code that causes that stuff to be used. Kevin Jennings
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