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
jonesandy@comcast.net wrote: > All three (voltage, temperature and process) vary over a > single die, but not by much. The trick is always "by how much?" > Are we willing to live with slower guaranteed performance in > order to simplify the analysis, or is it worth it to invest > more in the analysis (NRE) to "speed up" the parts > (recurring profit)? > Managing hold time is a lot more complicated than it used to be. > In the past, the clock skew could always be less than Tco plus > minimum routing by design, so they did not even spec hold time > for the registers. I do rememeber specs. of 0ns hold time. Hold time can even go negative in some cases. I think I remember some TTL parts with negative hold time, but that is some years ago. > Over time, the raw speed of the devices has > out-stripped the skew of the clock tree, and hold time is a real > problem that has to be taken care of in placement and routing. Xilinx used to publish actual books about their parts. We could read about them, understand them, and use them appropriately. Yes, I am remembering from some generations ago. > We users just don't have control over the clock tree itself to > deal with the problem, like in other domains. -- glenArticle: 154626
Hello. I'm having trouble using the "Platform Cable USB II" with my new linux box. Basically, when I plug the USB cable into a windows box, the green light comes on, but if I plug it into the Linux box, no light comes on. And impact does not connect to the cable. At first I got a message from impact saying to install windrvr 6. I ran the install script for that and now impact will just say that it cannot connect to the cable I've also tried a solution from General S. here for an earlier version of red hat which involved installing libusb and edits to the rules file, but that has not worked. Has anyone else had success with this combination? I have a web case which is crawling along at a snail's pace. How can Xilinx list this as a "supported" operating system? (rhetorical question) Thanks. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154627
On Monday, December 3, 2012 4:55:56 AM UTC-8, Allan Herriman wrote:
> Sorry I missed that earlier. You seem to be mixing up skew and delay.
>
> > datasheet BUFG delay is 0.10ns
>=20
> That figure is the BUFG skew, not the BUFG delay.
> It represents the worst case timing difference between outputs on the=20
> same BUFG. It isn't relevant to your problem.
>=20
>=20
> The "Clock Path Skew" is the important figure. It is the difference=20
> between the time of arrival of the clock at the source (clocked from=20
> BUFR) flip flops and destination (clocked from BUFG) flip flops. In this=
=20
> case it is mostly made up of the BUFG delay.
I don't think I am mixing skew w/ delay.
>From DS152 (Virtex 6 AC-DC):
Table 59: Global Clock Switching Characteristics (Including BUFGCTRL)
TBCCKO_O(2) BUFGCTRL delay from I0/I1 to O 0.07 0.08 0.10 0.10 ns
>From v6 speedprint:
BUFG
=20
Tbgcko_O (33/35) (66/70)
BUFGCTRL
Tbccko_O (33/35) (66/70)
So the delay through BUFGCTRL is small. However, the delay is much bigger s=
ince it includes the routing. Xilinx is not verbose with the clock path, or=
at least I don't know how to generate it....
For timingan report all I get is:
Clock Path Skew: 1.851ns (2.677 - 0.826)
Yes, it is skew; it is bigger than usual because the 1st clock (0.826ns ins=
ertion delay) is driven by the BUFR and the 2nd clock, the target, (2.677ns=
insertion delay) is driven by the BUFG fed by BUFR. The delta, 1.851ns, is=
much higher than the prop delay through the buffer - my interpretation is =
0.1ns in buffer, rest in routing and/or distribution (both to and from BUFG=
); we don't see netlists. I don't think Xilinx has much info about that clo=
ck routing available for general public.
--
mmihai
Article: 154628On Sunday, December 2, 2012 2:22:37 PM UTC-8, glen herrmannsfeldt wrote: > It seems to me that they do pretty well. I would not say 'pretty well'; they're not bad but not very good either. Otherwise I would not have problems on the hardware when I'm getting >0.0ns= hold slack. And form this thread I would say I am not alone seeing this pr= oblem and it is not happening for only one tool version/one chip. =20 > Well, the effects of voltage and temperature should be pretty > much the same for all transistors on a chip. But process variations > could be very different. Huh? Numbers for STA should cover PVT. That 'P' stands for process. I am no= t sure what is your idea: numbers could be wrong because the process has va= riations? > Now, it would be nice to say that some delay is not characterized > enough to use, and so far I haven't seen that they do say that, > but it isn't the tools' fault if the data isn't available. I would like to think they're extracting/characterizing all the delays invo= lved in their fabric.... otherwise nobody would use this devices, they won'= t work in a reliable fashion. For a successful STA you need good delay extraction and good algorithm for = design/constrains understanding and path computation. In this case both ext= raction/delay computation and timing analysis tools are from Xilinx. In my = case it looks the delays might be off.... but since the delay is from Xilin= x (and you have no 2nd choice) I'll still call it bad STA on their flow.... -- mmihaiArticle: 154629
On Monday, December 3, 2012 4:55:56 AM UTC-8, Allan Herriman wrote: > >> One solution might be to insert FFs clocked from the other edge of the > >> BUFG clock. > > > > I thought about that .... can't do it, the clock is fast and it > > won't meet setup for half clock cycle. > > It might not meet setup for half a clock cycle, but it doesn't have to! > The skew works in your favour when using opposite edges and the > requirement for setup time is half a clock cycle + 1.851ns. Unless you > have a GHz clock that doesn't sound too hard. I was starting to review that this weekend ... Could be the next logic level was had the issue.... because I ended with half clock cycle for the next stage. That should not be a problem though, I can add a new set of flops to realign to the proper edge w/o any logic in between. This is the path I am exploring right now. -- mmihaiArticle: 154630
libusb is the way to go, I'm using it sucessfully with Ubuntu/Gentoo/Centos/SLC6/... As long as the programmer led does not got orange or green its a fxload issue. make sure the firmware files and the rules are in place. try to run fxload by hand to see if it works. As soon as the LED is on you can try to find out where impact searches for libusb.so and create a symlink to your actual lib if needed. HTH On 12/03/2012 09:18 PM, hotrodtodd1968 wrote: > Hello. > > I'm having trouble using the "Platform Cable USB II" with my new linux > box. > > Basically, when I plug the USB cable into a windows box, the green light > comes on, but if I plug it into the Linux box, no light comes on. And > impact does not connect to the cable. > > At first I got a message from impact saying to install windrvr 6. I ran the > install script for that and now impact will just say that it cannot connect > to the cable > > I've also tried a solution from General S. here for an earlier version of > red hat which involved installing libusb and edits to the rules file, but > that has not worked. > > Has anyone else had success with this combination? > > I have a web case which is crawling along at a snail's pace. How can Xilinx > list this as a "supported" operating system? (rhetorical question) > > Thanks. > > > > --------------------------------------- > Posted through http://www.FPGARelated.com >Article: 154631
On Mon, 03 Dec 2012 12:29:40 -0800, mmihai wrote: > On Monday, December 3, 2012 4:55:56 AM UTC-8, Allan Herriman wrote: > >> Sorry I missed that earlier. You seem to be mixing up skew and delay. >> >> > datasheet BUFG delay is 0.10ns >> >> That figure is the BUFG skew, not the BUFG delay. >> It represents the worst case timing difference between outputs on the >> same BUFG. It isn't relevant to your problem. >> >> >> The "Clock Path Skew" is the important figure. It is the difference >> between the time of arrival of the clock at the source (clocked from >> BUFR) flip flops and destination (clocked from BUFG) flip flops. In >> this case it is mostly made up of the BUFG delay. > > I don't think I am mixing skew w/ delay. > > From DS152 (Virtex 6 AC-DC): > > Table 59: Global Clock Switching Characteristics (Including > BUFGCTRL) > > TBCCKO_O(2) BUFGCTRL delay from I0/I1 to O 0.07 0.08 0.10 0.10 ns > > From v6 speedprint: > > BUFG > > Tbgcko_O (33/35) > (66/70) > > BUFGCTRL > > Tbccko_O (33/35) > (66/70) > > So the delay through BUFGCTRL is small. However, the delay is much > bigger since it includes the routing. Xilinx is not verbose with the > clock path, or at least I don't know how to generate it.... > > For timingan report all I get is: > > Clock Path Skew: 1.851ns (2.677 - 0.826) > > Yes, it is skew; it is bigger than usual because the 1st clock (0.826ns > insertion delay) is driven by the BUFR and the 2nd clock, the target, > (2.677ns insertion delay) is driven by the BUFG fed by BUFR. The delta, > 1.851ns, is much higher than the prop delay through the buffer - my > interpretation is 0.1ns in buffer, rest in routing and/or distribution > (both to and from BUFG); we don't see netlists. I don't think Xilinx has > much info about that clock routing available for general public. Yes, I see those figures in the datasheet. They don't make much sense to me though - I'm fairly sure the actual delay through the BUFG is much larger than 0.10 ns worst case. Your STA results seems to be in agreement with me. This might be one of those cases where the datasheet timing model doesn't match reality. Total delay through the routing to the BUFG plus the BUFGMUX logic plus the distribution tree itself plus the routing out of the BUFG comes to 1.851ns. Since those figures can't really be separated (in that only their sum matters) Xilinx can assign any figure it wants to some internal part that gets published in the datasheet. All of this is speculation on my part, of course. It's unfortunate that knowlegable Xilinx staff don't contribute in this newsgroup. You could ask the same question on the Xilinx forums, but I find it's unusual to get a good answer there. Regards, AllanArticle: 154632
On Monday, December 3, 2012 1:56:49 PM UTC-8, Allan Herriman wrote: > Yes, I see those figures in the datasheet. They don't make much sense to > me though - I'm fairly sure the actual delay through the BUFG is much > larger than 0.10 ns worst case. Your STA results seems to be in > agreement with me. > > This might be one of those cases where the datasheet timing model doesn't > match reality. Total delay through the routing to the BUFG plus the > BUFGMUX logic plus the distribution tree itself plus the routing out of > the BUFG comes to 1.851ns. Since those figures can't really be separated > (in that only their sum matters) Xilinx can assign any figure it wants to > some internal part that gets published in the datasheet. I think we are on the same page here. I've just wanted to point I don't mix the skew with the delay :) I don't expect the clock tree to have a single big buffer (i.e. one gate) that drives it. I think the number for the datasheet is only one (input) gate form the clocktree, the following drivers & routing are lumped in the delay number reported in timingan. > All of this is speculation on my part, of course. It's unfortunate that > knowlegable Xilinx staff don't contribute in this newsgroup. You could > ask the same question on the Xilinx forums, but I find it's unusual to > get a good answer there. I do agree with you on this one too :) I've copied the head of this thread on Xilinx forums... no reply till now. -- mmihaiArticle: 154633
On Sunday, December 2, 2012 10:43:04 PM UTC-5, rickman wrote: > I didn't see anything like this in the blog code, there was no muxing of the clock. Where did you get the code shown above? I was replying to Thomas' post on Nov 28. I must've clicked the wrong 'Post Reply' button or something. Link is https://groups.google.com/forum/#!search/In$20DSP$20I$20guess$20you$20have$20in$20general$20only$20one$20clk$20and$20all$20modules$20/comp.arch.fpga/zec7-hbtrJ8/TJOleMXV490J KevinArticle: 154634
Hi All, I am designing a memory controller and I am using two clocks clk and clk_90. Phase difference between clk and clk_90 is 90 degree. I want to transfer multiple bit data between clk and clk_90. Should I use asynchronous fifo or two registers (same as two flop synchronization). Thanks in advance, Regards, Krupesh --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154635
Different phases of the same clock are not asynchronous. There is a defined= timing relationship between clk and clk_90 in your case, right? If the dat= a can propagate between the two phases within that time (less setup), then = you can just transfer the date directly between registers clocked by each p= hase with no problems. If the time is not long enough, there are other choices: You have four clock edges total. You can use more than just the initial and= destination edges in your transition, and you don't have to do it all at o= nce. Assuming clk_90's rising edge is a quarter period after clk's rising_e= dge: You could transfer from rising_edge(clk) to falling_edge(clk_90) in 3/4 per= iod), and then to rising_edge(clk_90) in 1/2 period.=20 Or you could transfer from rising_edge(clk) to falling_edge(clk) in 1/2 per= iod, and then to rising_edge(clk_90) in 3/4 period. Either of these allows = at least a half clock period to propagate the data in each step.=20 If you cannot make the transition in half a clock period (really fast clock= !), you could transition in three steps: From rising_edge(clk) to falling_e= dge(clk_90), then to falling_edge(clk), and finally to rising_edge(clk_90).= Each of these are 3/4 period transfers.=20 As long as the tool understands the timing relationship between the two rel= ated clocks, it will correctly analyze the timing on transfers between them= , and report any problems. AndyArticle: 154636
On 12/3/2012 9:22 PM, KJ wrote: > On Sunday, December 2, 2012 10:43:04 PM UTC-5, rickman wrote: >> I didn't see anything like this in the blog code, there was no muxing of the clock. Where did you get the code shown above? > > I was replying to Thomas' post on Nov 28. I must've clicked the wrong 'Post Reply' button or something. Link is > https://groups.google.com/forum/#!search/In$20DSP$20I$20guess$20you$20have$20in$20general$20only$20one$20clk$20and$20all$20modules$20/comp.arch.fpga/zec7-hbtrJ8/TJOleMXV490J > > Kevin Ok, I finally found it, no thanks to Google groups. Somehow the post didn't link to the right place in my reader. I've seen it screw up before. I've kinda lost track of your point. But Thomas seems to be correct in what he said. But your point is correct, that adding logic delays to the clock distribution makes life difficult. I believe the tools typically handle that. If they didn't you would be limited to the number of global clock routes on a chip. In the real world you can have local clock distribution and the timing tools should verify and report setup and hold timing violations. Certainly adding logic to clock distribution makes things much more complex. RickArticle: 154637
We are looking for testers/evaluators of our newly released MXP Matrix proc= essor for Altera FPGAs (Xilinx very soon). This is a solution that enhances= NIOS II(microblaze) processor by up to a 1000x for many SIMD type algorith= ms. It is also 100% programmable in C/C++ If you are interested, or have project that you want to try it out with, pl= ease respond or send us a note at vectorblox.comArticle: 154638
Hi Andy, Thank you very much for your quick reply. Frequency of both the clocks are 100Mhz. So data should be stable before 2.5ns - set up time if data is transferred between clk clock to clk_90 clock directly. I am using Quartus II tool for CDC test which report warnings that multiple data bits are transferred asynchronously. I think it can be ignored. If its not working then I can try other alternatives as you suggested. Thanking you, Krupesh >Different phases of the same clock are not asynchronous. There is a defined= > timing relationship between clk and clk_90 in your case, right? If the dat= >a can propagate between the two phases within that time (less setup), then = >you can just transfer the date directly between registers clocked by each p= >hase with no problems. > >If the time is not long enough, there are other choices: > >You have four clock edges total. You can use more than just the initial and= > destination edges in your transition, and you don't have to do it all at o= >nce. Assuming clk_90's rising edge is a quarter period after clk's rising_e= >dge: > >You could transfer from rising_edge(clk) to falling_edge(clk_90) in 3/4 per= >iod), and then to rising_edge(clk_90) in 1/2 period.=20 > >Or you could transfer from rising_edge(clk) to falling_edge(clk) in 1/2 per= >iod, and then to rising_edge(clk_90) in 3/4 period. Either of these allows = >at least a half clock period to propagate the data in each step.=20 > >If you cannot make the transition in half a clock period (really fast clock= >!), you could transition in three steps: From rising_edge(clk) to falling_e= >dge(clk_90), then to falling_edge(clk), and finally to rising_edge(clk_90).= > Each of these are 3/4 period transfers.=20 > >As long as the tool understands the timing relationship between the two rel= >ated clocks, it will correctly analyze the timing on transfers between them= >, and report any problems. > >Andy > --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154639
Assume register r4 is driven by three registers r1, r2, r3 registers r1, r2, r3 drive out their data every 3 clocks, each on a different clock phase. r1 is driven successively in the order of r1,r2,r3 such that the D input of register r4 is changing every clock. Now, if I assign multicycle of 3 on r1 then I assume r1, r2, r3 each will each launch its data without violating r1. so reg r1 can be assigned multicycle of 3 despite its input changing every clock cycle. Any thoughts on that? Kaz --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154640
correcting typos: Assume register r4 is driven by three registers r1, r2, r3 registers r1, r2, r3 drive out their data every 3 clocks, each on a different clock phase. r4 is driven successively in the order of r1,r2,r3 such that the D input of register r4 is changing every clock. Now, if I assign multicycle of 3 on r4 then I assume r1, r2, r3 each will each launch its data without violating r4. so reg r4 can be assigned multicycle of 3 despite its input changing every clock cycle. Any thoughts on that? Kaz --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154641
On Sat, 08 Dec 2012 00:47:40 -0600, kaz wrote: > correcting typos: > > Assume register r4 is driven by three registers r1, r2, r3 registers r1, > r2, r3 drive out their data every 3 clocks, each on a different clock > phase. r4 is driven successively in the order of r1,r2,r3 such that the > D input of register r4 is changing every clock. > > Now, if I assign multicycle of 3 on r4 then I assume r1, r2, r3 each > will each launch its data without violating r4. Not quite because there has to be a way of selecting which of R1 ..R3 drives R4. And it won't be implemented as tristates but as a multiplexer, whose outputs (R4 inputs) must settle in a single cycle. It may be permissible to identify paths specifically from R1..R3 to R4 and multi-cycle those, as long as you can identify the select signals and ensure they (and therefore the mux) are single cycle, but simply assigning multicycle on R4 inputs is asking for trouble. (and in a real world design I would be very surprised if it gave you any advantage over straightforward single cycle constraints. If it does, please post numbers!) - BrianArticle: 154642
>On Sat, 08 Dec 2012 00:47:40 -0600, kaz wrote: > >> correcting typos: >> >> Assume register r4 is driven by three registers r1, r2, r3 registers r1, >> r2, r3 drive out their data every 3 clocks, each on a different clock >> phase. r4 is driven successively in the order of r1,r2,r3 such that the >> D input of register r4 is changing every clock. >> >> Now, if I assign multicycle of 3 on r4 then I assume r1, r2, r3 each >> will each launch its data without violating r4. > >Not quite because there has to be a way of selecting which of R1 ..R3 >drives R4. And it won't be implemented as tristates but as a multiplexer, >whose outputs (R4 inputs) must settle in a single cycle. > >It may be permissible to identify paths specifically from R1..R3 to R4 >and multi-cycle those, as long as you can identify the select signals and >ensure they (and therefore the mux) are single cycle, but simply >assigning multicycle on R4 inputs is asking for trouble. > >(and in a real world design I would be very surprised if it gave you any >advantage over straightforward single cycle constraints. If it does, >please post numbers!) > >- Brian > Thanks Brian, good point. However, I am assuming some friendly fitter that takes care of data across the mux as well i.e. r1 launches its data that is made available when sampled after 3 clocks then r2 and so on in a queue, and each sampled at correct phase by the design. Of course if the fitter doesn't respect the order of queue right to D input, then I am in trouble. I haven't implemented to see the benefit but I am short of speed and looking for any deconstraints. Kaz --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154643
I assume the bay area is number one for embedded software engineers, but where else are the big markets, as companies run from califoria taxes. Denver, CO - Does big population mean high tech? Phoenix, AZ - Sun birds. Albuquerque, NM - Sun birds, ballon festival. Salt Lake City, UT - Mormons, big population. Portland, OR - Big population. Seattle, WA - All those ex-Microsofties starting companies. Which of these are go, or no-go? And if the bay area is it, where in the bay area?Article: 154644
On 12/9/2012 6:04 PM, no one wrote: > I assume the bay area is number one for embedded software engineers, > but where else are the big markets, as companies run from califoria taxes. > > Denver, CO - Does big population mean high tech? > Phoenix, AZ - Sun birds. > Albuquerque, NM - Sun birds, ballon festival. > Salt Lake City, UT - Mormons, big population. > Portland, OR - Big population. > Seattle, WA - All those ex-Microsofties starting companies. > > Which of these are go, or no-go? > > And if the bay area is it, where in the bay area? > I see by your list, you are not going East of the Miss. Embedded Software Engineers is no longer a term of embedded processor engineers. Everyone uses it anymore, so you really need to be specific about _your_ definition of embedded engineer. As this is an FPGA newsgroup, do you mean Embedded FPGA engineer ? Do you mean assembly language / C language Embedded Engineer ? hamilton PS: Don't Come to Denver, we have too many UN-employed engineers already.Article: 154645
On 8 Dez., 07:47, "kaz" <3619@embeddedrelated> wrote: > Now, if I assign multicycle of 3 on r4 then I assume r1, r2, r3 each will > each > launch its data without violating r4. > > so reg r4 can be assigned multicycle of 3 despite its input changing every > clock cycle. > > Any thoughts on that? This is not multicycle. Assume your logicone has the points P1-P3 before the multiplexing, than you could multicycle the path from r1 to P1, r2 to P2,.. but I don't think any tool would handle that constraint correct. You could insert registers before the multiplexing structure. That would allow to set multicycle of 2 clock cycles without loosing latency, but would require carefule enable generation of that register. best regards ThomasArticle: 154646
Hi Andy, I can successfully transfer data between clk and clk_90 clock without getting any timing violation or CDC warnings. Thanking you, Krupesh. >Hi Andy, > >Thank you very much for your quick reply. > >Frequency of both the clocks are 100Mhz. So data should be stable before >2.5ns - set up time if data is transferred between clk clock to clk_90 >clock directly. I am using Quartus II tool for CDC test which report >warnings that multiple data bits are transferred asynchronously. I think it >can be ignored. >If its not working then I can try other alternatives as you suggested. > >Thanking you, > >Krupesh > > >>Different phases of the same clock are not asynchronous. There is a >defined= >> timing relationship between clk and clk_90 in your case, right? If the >dat= >>a can propagate between the two phases within that time (less setup), then >= >>you can just transfer the date directly between registers clocked by each >p= >>hase with no problems. >> >>If the time is not long enough, there are other choices: >> >>You have four clock edges total. You can use more than just the initial >and= >> destination edges in your transition, and you don't have to do it all at >o= >>nce. Assuming clk_90's rising edge is a quarter period after clk's >rising_e= >>dge: >> >>You could transfer from rising_edge(clk) to falling_edge(clk_90) in 3/4 >per= >>iod), and then to rising_edge(clk_90) in 1/2 period.=20 >> >>Or you could transfer from rising_edge(clk) to falling_edge(clk) in 1/2 >per= >>iod, and then to rising_edge(clk_90) in 3/4 period. Either of these allows >= >>at least a half clock period to propagate the data in each step.=20 >> >>If you cannot make the transition in half a clock period (really fast >clock= >>!), you could transition in three steps: From rising_edge(clk) to >falling_e= >>dge(clk_90), then to falling_edge(clk), and finally to >rising_edge(clk_90).= >> Each of these are 3/4 period transfers.=20 >> >>As long as the tool understands the timing relationship between the two >rel= >>ated clocks, it will correctly analyze the timing on transfers between >them= >>, and report any problems. >> >>Andy >> > >--------------------------------------- >Posted through http://www.FPGARelated.com > --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154647
Hi Andy, I can successfully transfer data between clk and clk_90 clock without getting any timing violation or CDC warnings. Thanking you, Krupesh. >Hi Andy, > >Thank you very much for your quick reply. > >Frequency of both the clocks are 100Mhz. So data should be stable before >2.5ns - set up time if data is transferred between clk clock to clk_90 >clock directly. I am using Quartus II tool for CDC test which report >warnings that multiple data bits are transferred asynchronously. I think it >can be ignored. >If its not working then I can try other alternatives as you suggested. > >Thanking you, > >Krupesh > > >>Different phases of the same clock are not asynchronous. There is a >defined= >> timing relationship between clk and clk_90 in your case, right? If the >dat= >>a can propagate between the two phases within that time (less setup), then >= >>you can just transfer the date directly between registers clocked by each >p= >>hase with no problems. >> >>If the time is not long enough, there are other choices: >> >>You have four clock edges total. You can use more than just the initial >and= >> destination edges in your transition, and you don't have to do it all at >o= >>nce. Assuming clk_90's rising edge is a quarter period after clk's >rising_e= >>dge: >> >>You could transfer from rising_edge(clk) to falling_edge(clk_90) in 3/4 >per= >>iod), and then to rising_edge(clk_90) in 1/2 period.=20 >> >>Or you could transfer from rising_edge(clk) to falling_edge(clk) in 1/2 >per= >>iod, and then to rising_edge(clk_90) in 3/4 period. Either of these allows >= >>at least a half clock period to propagate the data in each step.=20 >> >>If you cannot make the transition in half a clock period (really fast >clock= >>!), you could transition in three steps: From rising_edge(clk) to >falling_e= >>dge(clk_90), then to falling_edge(clk), and finally to >rising_edge(clk_90).= >> Each of these are 3/4 period transfers.=20 >> >>As long as the tool understands the timing relationship between the two >rel= >>ated clocks, it will correctly analyze the timing on transfers between >them= >>, and report any problems. >> >>Andy >> > >--------------------------------------- >Posted through http://www.FPGARelated.com > --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154648
On Sat, 08 Dec 2012 04:42:34 -0600, kaz wrote: >>On Sat, 08 Dec 2012 00:47:40 -0600, kaz wrote: >> >>> correcting typos: >>> >>> Assume register r4 is driven by three registers r1, r2, r3 registers > r1, >>> r2, r3 drive out their data every 3 clocks, each on a different clock >>> phase. r4 is driven successively in the order of r1,r2,r3 such that >>> the D input of register r4 is changing every clock. >>> >>> Now, if I assign multicycle of 3 on r4 then I assume r1, r2, r3 each >>> will each launch its data without violating r4. >> >>Not quite because there has to be a way of selecting which of R1 ..R3 >>drives R4. And it won't be implemented as tristates but as a >>multiplexer, > >>whose outputs (R4 inputs) must settle in a single cycle. >> >>It may be permissible to identify paths specifically from R1..R3 to R4 >>and multi-cycle those, as long as you can identify the select signals >>and > >>ensure they (and therefore the mux) are single cycle, but simply >>assigning multicycle on R4 inputs is asking for trouble. >> >>(and in a real world design I would be very surprised if it gave you any >>advantage over straightforward single cycle constraints. If it does, >>please post numbers!) >> >>- Brian >> >> > Thanks Brian, good point. > > However, I am assuming some friendly fitter that takes care of data > across > > the mux as well i.e. r1 launches its data that is made available when > sampled after 3 clocks then r2 and so on in a queue, and each sampled at > correct phase by the design. Simply won't work. If you try to multicycle the mux, that can only work by starting to drive R3 to the outputs before R3's phase - i.e. during R2's or even R1's. In which case, the fast paths arrive at the output a cycle or two too early! Therefore any path from the mux inputs onwards is strictly single cycle. Unless by "sampling at the correct phase" you meant "sampling and holding..." in which case you are just introducing more registers. That potentially works but there isn't much scope to pipeline a 3:1 MUX! You could potentially pipeline it as two 2:1 muxes with a reg in between them (and a compensating reg for the 3rd input) but you'd have to be working right at the edge of the FPGA's speed capability for this to be worthwhile (well over 500MHz in Virtex-5 for example) The only other benefit of extra regs would be to hide excessive routing delay. If that's your problem then the simplest answer is to LOC R1, R2, R3, the mux and Rout next to each other in the floorplanner, and introduce extra pipe stage if that doesn't work. - BrianArticle: 154649
On 10/12/2012 02:04, no one wrote: > I assume the bay area is number one for embedded software engineers, > but where else are the big markets, as companies run from califoria taxes. > > Denver, CO - Does big population mean high tech? > Phoenix, AZ - Sun birds. > Albuquerque, NM - Sun birds, ballon festival. > Salt Lake City, UT - Mormons, big population. > Portland, OR - Big population. > Seattle, WA - All those ex-Microsofties starting companies. > > Which of these are go, or no-go? > > And if the bay area is it, where in the bay area? > This is an international group, not an American group - "the bay area" is meaningless outside your country. And since the world extends a long way outside the USA, have you considered moving abroad? Certainly Norway has a great shortage of engineers.
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