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
"Mr.CRC" <crobcBOGUS@REMOVETHISsbcglobal.net> wrote in message news:iqm4ri02prr@news4.newsguy.com... > Andrew Holme wrote: >> "Mr.CRC" <crobcBOGUS@REMOVETHISsbcglobal.net> wrote in message >> news:iqkvcv01c5r@news6.newsguy.com... >>> reg [15:0] cnt; >>> >>> always @ (posedge clk) begin >>> if (cnt == MAX_CNT) >>> cnt = 0; >>> else >>> cnt = cnt + 1; >>> end >>> >>> assign a = ~cnt[1]; >>> assign b = cnt[1] ^ cnt[0]; >>> assign m = ~b & (cnt == 0 || cnt == MAX_CNT); >>> // index pulse m is high >>> // straddling max count and zero. Why the redundant '&' with ~b is >>> // performed? I forget. Maybe this is unnecessary. >>> endmodule >> >> >> This module qep_sim will have glitches in the middle of the high pulse on >> output b when cnt[1] changes picoseconds before cnt[0] as it can do, >> depending on internal routing. > > > Yes, I see. Not sure why I didn't think of that. Now this reminds me > that the reason why m includes the & ~b is to prevent a glitch on m when > the cnt goes from MAX_CNT->0. But of course, that presumes b doesn't > have glitches... > > I will try to work this out. > > BTW, the potential glitching you describe has never actually been > observed from this module. Though with my slow slew rate outputs, it > may have just been unobservable externally. > > > So this is a seperate issue from the original problem, which is that cnt > changes on the wrong edge of the clock sometimes. If it's an external clock, slow rise and fall times plus additive noise can cause multiple counts if it slews too slowly through the logic threshold. If the external clock rate is low, the best solution is to sample it at a rate comparable to the rise/fall time.Article: 151751
On Sat, 14 May 2011 14:35:06 +0200, Michael wrote: > Hi, > > On 05/14/11 01:04 PM, maxascent wrote: >> I misunderstood and thought that you where saying that you had a design >> in 9.2 which was fine and after moving to 13 you have problems. I guess >> it depends by how much you are missing timing to if Synplify would help >> you. Personally I would think it will not make a big improvement over >> XST. >> >> Jon > No,I have design and it needs to be improved I and I don't belive in > some fantastic tool or miracle which means that I need to try and gain > 10-15% here and there in the hope that the result will be the 50-60% I > need to make it work. > Don't expect 50-60% speed improvement from a different synthesis tool! Look at re-architecting the design itself. Identify the slow parts and improve them. If you can add one or more pipeline stages this is relatively easy, but if you can't add a pipeline stage, can you move part of the critical computation to an earlier or later stage? There are some benefits to be had from floorplanning the speed-critical sections, perhaps explore if PlanAhead can help you meet your targets. Finally, the next highest speed grade on the chip itself may be worth up to 15%. - BrianArticle: 151752
On May 14, 11:27=A0am, "Mr.CRC" <crobcBO...@REMOVETHISsbcglobal.net>
wrote:
> Joel Williams wrote:
> >> Thanks for ideas on what might be wrong. =A0I suspect it has something=
to
> >> do with non-ideal choices of IO pins for the clock inputs. =A0I didn't
> >> have time to test this today, but I suspect if I simply move the
> >> ext_sim_clk to a different pin, the problem will go away.
>
> > Rather than using these signals as clocks, why not sample the incoming
> > signal with the Nexys2's 50 MHz clock?
>
> > Register the input and check for rising edges:
>
> > reg [1:0] ext_clk;
>
> > always @(posedge clk50)
> > =A0 ext_clk[1:0] <=3D {ext_clk[0], sim_clk};
>
> > wire rising_edge =3D ext_clk[1] & ~ext_clk[0];
>
> > and then count these:
>
> > always @(posedge clk50)
> > =A0 if (rising_edge)
> > =A0 =A0 if (cnt =3D=3D MAX_CNT) ...
>
> I could probably do something like this.
>
> BTW, doesn't the above produce 20ns pulses on "rising_edge" when sim_clk
> goes H->L, ie. on the falling edge?
Yes. The expression should be ~ext_clk[1] & ext_clk[0] for a rising
edge detect.
> Also, I wonder about the use of a once-registered asynchronous input
> signal. =A0Shouldn't the sim_clk be registered at least twice before
> engaging in combinatorial functions? =A0Ie, it seems that if ext_clk[0]
> waffles for a few extra ns due to metastability, then the pulse on
> "rising_edge" could be shorter than 20ns and not reliable.
Are you using rising_edge as a pulse with a defined width or is it an
enable to the next FF? You can resolve metastability anywhere along
this chain, as long as you do it before the signal branches out to
more than one place.
> Wouldn't it make more sense to simply use:
>
> wire rising_edge =3D ext_clk[1] & ext_clk[0]; // ???
No, this does not detect an edge. This resolves metastability and
eliminates glitches, but you still need to detect the edge of the
clock signal. The idea of detecting the edge is to both bring the
signal into the clk50 domain and also create a one clock period wide
enable to use in place of a separate clock.
> In which case I think it is safe even employing the once-registered
> ext_clk[0] ?
No, this doesn't even resolve metastability unless you provide more
slack time to the next FF.
> There is still an unresolved engineering principles question here
> though. =A0Do FPGA logic designers ALWAYS sync asynchronous inputs to the
> internal clock? =A0
"Always" is a big statement. I nearly always pick one fast clock
domain as the "internal" clock and sync slow clocks to this fast one.
Each "external" clock becomes a clock enable internally. There are
times when I use the external clock directly, for example the serial
clock on an SPI port directly clocks the shift register in a recent
SPI design. Then I have lots of time to sync the parallel word to the
internal clock. But this could be done either way. Sometimes it
depends on the relative rate of the two clocks. The closer in speed
they are the harder it can be to fully analyze the timing.
> If there is a circuit which is to be clocked by an
> external source, and it is not going to interact with other process on
> different clocks, then why bother syncing this clock input to the 50MHz
> on-board clock? =A0Ie, my qep_sim.v exists in its own clock domain, albei=
t
> there is still the mux to choose which external clock to use.
If it is completely independent as if it were being done on a separate
chip, then yes, there is no reason to sync it to the internal clock as
long as you can get the clock to a clock input and even that is not
essential. The tools have to do less work to make a clock on a clock
tree meet setup and hold times.
> This also doesn't answer the question of why the behavior changes vs.
> input pin.
I suspect that has to do with your clock signal. Does it have a slow
rise/fall time? I suspect a bit of noise is making it double clock.
When you route it differently (since it is not on a clock IO pin) the
glitch can get filtered out depending on how it is routed. It only
takes a very tiny glitch to cause this sort of double clocking and
such a tiny glitch can be filtered by the random routing. Putting it
on a global clock tree should make it fail more often.
> I have gathered that when clocks are to be brought in to the FPGA, it is
> highly recommended to use a GCLK IO pin, so the signal may be buffered
> onto a global clock routing line. =A0I have to see if I can rearrange my
> IOs to get these external inputs onto GCLK IOs, but there are two of
> them and the NEXYS2 isn't very liberal about providing GCLKs on the pin
> headers. =A0Some other GCLKs are available on another connector, but I
> don't yet have the mating for that.
Don't try to fix a problem if you don't understand the cause. Why
would a GLK IO pin eliminate your problem?
> Of course, when muxing external clock sources, if there are a lot of
> them, one could eat into the supply of GCLKs quickly, so this is
> undesirable.
Bingo! That is a big reason for treating slow clocks as clock enables
on an internal clock.
> A more interesting question is then, is it possible to take a GP IO
> input pin, and internally buffer it onto an internal clock routing line?
Isn't that what is already happening in your case?
> Thanks for input and clarification.
Let us know what you find. It is hard to analyze problems like this
without doing tests. I may be completely off base in this case.
Rick
Article: 151753On May 14, 7:37=A0am, wzab <wza...@gmail.com> wrote: > On May 14, 12:40=A0am, rickman <gnu...@gmail.com> wrote: > > > Perhaps I don't understand what you are asking. =A0The web page says > > there is a development system supported under gforth. > > > "Cross compiler runs on Windows, Mac and Unix" > > > Are you talking about extending the hardware design rather than new > > words in Forth? > > Well, this requires both extension of hardware (bidirectional port) > and extension of Forth (compiler words in target system). > > > Oh, you mean "interactive" rather than batch mode... I get it. =A0No, > > that would require a certain amount of work on run time code on the > > device as well as supporting code on the host system. > > On the host system the minicom for UART connection should be enough. > For JTAG connection I have ready to use open solutions which may > provide conectivity > to such bidirectional port.https://groups.google.com/group/alt.sources/br= owse_thread/thread/3818...https://groups.google.com/group/alt.sources/brows= e_thread/thread/603f... > > > You might take a look at Riscy Pygness. =A0They have already done this > > for the ARM processor I believe. =A0It might be easier to adapt that > > code to the J1 app than to reinvent (or recode) the wheel. > > Well, what I expect to have is something like amforth (http://amforth.sf.= net > ) > but without implementing of ARM core in FPGA. > In fact I have already succesfully experimented with similar solution > based on > 6809 core published on googlecode :http://code.google.com/p/rekonstrukt/ > However the 6809 SoC is slow and resource hungry. J1 is both faster > and simpler. > > BTW I have found, that the sources mentioned in the J1 paper as > published under BSD > license:http://excamera.com/files/j1.pdf > and which may be downloaded via: > svn cohttps://code.ros.org/svn/ros-pkg/stacks/camera_drivers/trunk/wge100= _c... > are much better for experiments then j1demo.tar.gz (eg.they allow you > to use different Ethernet > PHY). > > WZab At this point I can't say I understand what you are asking. Do you have something specific you are asking about or have you figured it out at this point? RickArticle: 151754
On May 14, 7:37=A0am, wzab <wza...@gmail.com> wrote: > On May 14, 12:40=A0am, rickman <gnu...@gmail.com> wrote: > > > Perhaps I don't understand what you are asking. =A0The web page says > > there is a development system supported under gforth. > > > "Cross compiler runs on Windows, Mac and Unix" > > > Are you talking about extending the hardware design rather than new > > words in Forth? > > Well, this requires both extension of hardware (bidirectional port) > and extension of Forth (compiler words in target system). > > > Oh, you mean "interactive" rather than batch mode... I get it. =A0No, > > that would require a certain amount of work on run time code on the > > device as well as supporting code on the host system. > > On the host system the minicom for UART connection should be enough. > For JTAG connection I have ready to use open solutions which may > provide conectivity > to such bidirectional port.https://groups.google.com/group/alt.sources/br= owse_thread/thread/3818...https://groups.google.com/group/alt.sources/brows= e_thread/thread/603f... > > > You might take a look at Riscy Pygness. =A0They have already done this > > for the ARM processor I believe. =A0It might be easier to adapt that > > code to the J1 app than to reinvent (or recode) the wheel. > > Well, what I expect to have is something like amforth (http://amforth.sf.= net > ) > but without implementing of ARM core in FPGA. > In fact I have already succesfully experimented with similar solution > based on > 6809 core published on googlecode :http://code.google.com/p/rekonstrukt/ > However the 6809 SoC is slow and resource hungry. J1 is both faster > and simpler. > > BTW I have found, that the sources mentioned in the J1 paper as > published under BSD > license:http://excamera.com/files/j1.pdf > and which may be downloaded via: > svn cohttps://code.ros.org/svn/ros-pkg/stacks/camera_drivers/trunk/wge100= _c... > are much better for experiments then j1demo.tar.gz (eg.they allow you > to use different Ethernet > PHY). > > WZab BTW, you might want to crosspost this to comp.lang.forth. RickArticle: 151755
On May 14, 11:27=A0am, "Mr.CRC" <crobcBO...@REMOVETHISsbcglobal.net> wrote: > > There is still an unresolved engineering principles question here > though. =A0Do FPGA logic designers ALWAYS sync asynchronous inputs to the > internal clock? =A0 They do if they want to guarantee it will work and be maintainable and/ or reusable. Either that or they come back here posting about a design that 'used to work just fine when...blah, blah, and now it does not' > If there is a circuit which is to be clocked by an > external source, and it is not going to interact with other process on > different clocks, then why bother syncing this clock input to the 50MHz > on-board clock? You wouldn't. The point of synchronizing to a clock is when you're *changing* clock domains. > =A0Ie, my qep_sim.v exists in its own clock domain, albeit > there is still the mux to choose which external clock to use. > The output of the clock mux is a new clock domain, different than either of the two input clock domains. Thinking that the selected input clock and the 'output of the mux clock' are the same clock domain is a mistake that will come back to bite you. > This also doesn't answer the question of why the behavior changes vs. > input pin. > Because sometimes you get 'lucky'. There are probably lots of things (such as moving pins, hand routing, etc.) that you can do to appear to 'fix' the problem. If you're lucky you'll find that none of these things really works well and that you still occasionally get glitches. If you're not lucky you won't find this out until much later when it will get more and more difficult and expensive to fix if you've deployed many of these boards. If you'd rather be smart than lucky you'll stop using gated internal clocks and adopt synchronous design practices. > I have gathered that when clocks are to be brought in to the FPGA, it is > highly recommended to use a GCLK IO pin, so the signal may be buffered > onto a global clock routing line. =A0 It is even more recommended that you not generate your own internal clocks with logic. > I have to see if I can rearrange my > IOs to get these external inputs onto GCLK IOs, but there are two of > them and the NEXYS2 isn't very liberal about providing GCLKs on the pin > headers. =A0Some other GCLKs are available on another connector, but I > don't yet have the mating for that. > This would be some of the tricks that I mentioned earlier that, if you're lucky, you'll find are not robust without spending too much time. Or maybe your luck will run out, the design will appear to work, you'll think you're home free...until a couple of months later when you're handed a stack of boards that aren't qute working and you need to fix them. > Of course, when muxing external clock sources, if there are a lot of > them, one could eat into the supply of GCLKs quickly, so this is > undesirable. > Yep...you shouldn't do that. > A more interesting question is then, is it possible to take a GP IO > input pin, and internally buffer it onto an internal clock routing line? > I may be an interesting question...but you'll get to the end line much sooner if you use strictly synchronous practices and only cross clock domains either with dual clock fifos or proper synchronization logic. Kevin JenningsArticle: 151756
>> BTW, doesn't the above produce 20ns pulses on "rising_edge" when sim_clk >> goes H->L, ie. on the falling edge? > > Yes. The expression should be ~ext_clk[1]& ext_clk[0] for a rising > edge detect. My mistake, sorry! I'm just glad that everyone agreed with me about the method :D JoelArticle: 151757
Andrew Holme wrote: > > If it's an external clock, slow rise and fall times plus additive noise can > cause multiple counts if it slews too slowly through the logic threshold. > If the external clock rate is low, the best solution is to sample it at a > rate comparable to the rise/fall time. Thanks for the reply. Ugh. I could have sworn a few minutes ago I found a spec of 500ns for the min slew rate of an input in the hideous ds312.pdf "Spartan-3E FPGA Family: Data Sheet" but now I can't find it again. Anyway, getting a clean enough clock to a logic device really isn't that hard. I'll scope it again Monday and see if I can't put it up somewhere. -- _____________________ Mr.CRC crobcBOGUS@REMOVETHISsbcglobal.net SuSE 10.3 Linux 2.6.22.17Article: 151758
HI, On 05/14/11 09:32 PM, Brian Drummond wrote: > On Sat, 14 May 2011 14:35:06 +0200, Michael wrote: > >> Hi, >> >> On 05/14/11 01:04 PM, maxascent wrote: >>> I misunderstood and thought that you where saying that you had a design >>> in 9.2 which was fine and after moving to 13 you have problems. I guess >>> it depends by how much you are missing timing to if Synplify would help >>> you. Personally I would think it will not make a big improvement over >>> XST. >>> >>> Jon >> No,I have design and it needs to be improved I and I don't belive in >> some fantastic tool or miracle which means that I need to try and gain >> 10-15% here and there in the hope that the result will be the 50-60% I >> need to make it work. >> > > Don't expect 50-60% speed improvement from a different synthesis tool! For sure no, I was hoping that a change of synth would make say 10-15% then I would make it a go. But, have you used any other synth tools lately? > Look at re-architecting the design itself. Identify the slow parts and > improve them. If you can add one or more pipeline stages this is > relatively easy, but if you can't add a pipeline stage, can you move part > of the critical computation to an earlier or later stage? > This is where I expect to gain the remaining 30-40 %, but as I wrote I need to try both a tool change and recoding some parts. > There are some benefits to be had from floorplanning the speed-critical > sections, perhaps explore if PlanAhead can help you meet your targets. > Hmm, I have actually never exlored PlanAhead if that would help. Have you used it? > Finally, the next highest speed grade on the chip itself may be worth up > to 15%. > > - Brian I already have the fastest and all boards are also already made and in use so that is not an option. /michaelArticle: 151759
On Sun, 15 May 2011 08:47:21 +0200, Michael wrote: > HI, > > On 05/14/11 09:32 PM, Brian Drummond wrote: >> On Sat, 14 May 2011 14:35:06 +0200, Michael wrote: >> Don't expect 50-60% speed improvement from a different synthesis tool! > For sure no, I was hoping that a change of synth would make say 10-15% > then I would make it a go. > > But, have you used any other synth tools lately? Mentor Leonardo (years ago!) but not lately. I found my time better spent on improving the design, but YMMV. >> Look at re-architecting the design itself. > This is where I expect to gain the remaining 30-40 %, but as I wrote I > need to try both a tool change and recoding some parts. Do you have any specific reason for believing the improvement here is so limited? >> There are some benefits to be had from floorplanning the speed-critical >> sections, perhaps explore if PlanAhead can help you meet your targets. >> > Hmm, I have actually never exlored PlanAhead if that would help. Have > you used it? Not PlanAhead but in the ISE 6.1/7.1 era I played extensively with the earlier Floorplanner, now replaced by PlanAhead. It had serious problems supporting hierarchical and reusable blocks, but... I could take a block that PARed at 80MHz and get 120MHz out of it with careful floorplanning, and (working around said problems) reuse that block multiple times with PAR placing less critical parts of the design. However, above a certain level of congestion, PAR would route other signals through my carefully floorplanned blocks, destroying some of the additional performance. Now (1) I can't say how this gain transfers to PlanAhead, and (2) PAR might get closer to optimal performance these days, but it's definitely worth looking into as a source of improvement. - BrianArticle: 151760
Michael <michael_laajanen@yahoo.com> wrote: >HI, > >On 05/14/11 09:32 PM, Brian Drummond wrote: >> On Sat, 14 May 2011 14:35:06 +0200, Michael wrote: >> >>> Hi, >>> >>> On 05/14/11 01:04 PM, maxascent wrote: >>>> I misunderstood and thought that you where saying that you had a design >>>> in 9.2 which was fine and after moving to 13 you have problems. I guess >>>> it depends by how much you are missing timing to if Synplify would help >>>> you. Personally I would think it will not make a big improvement over >>>> XST. >>>> >>>> Jon >>> No,I have design and it needs to be improved I and I don't belive in >>> some fantastic tool or miracle which means that I need to try and gain >>> 10-15% here and there in the hope that the result will be the 50-60% I >>> need to make it work. >>> >> >> Don't expect 50-60% speed improvement from a different synthesis tool! >For sure no, I was hoping that a change of synth would make say 10-15% >then I would make it a go. > >But, have you used any other synth tools lately? > >> Look at re-architecting the design itself. Identify the slow parts and >> improve them. If you can add one or more pipeline stages this is >> relatively easy, but if you can't add a pipeline stage, can you move part >> of the critical computation to an earlier or later stage? >> >This is where I expect to gain the remaining 30-40 %, but as I wrote I >need to try both a tool change and recoding some parts. >> There are some benefits to be had from floorplanning the speed-critical >> sections, perhaps explore if PlanAhead can help you meet your targets. >> >Hmm, I have actually never exlored PlanAhead if that would help. Have >you used it? > >> Finally, the next highest speed grade on the chip itself may be worth up >> to 15%. >> >> - Brian >I already have the fastest and all boards are also already made and in >use so that is not an option. It also helps to play with the synthesis and PAR parameters. This is a tedious process because it needs re-running the whole process many times. The defaults most certainly will not get you the best results! Turning on 'optimisation beyond hierarchical blocks' gives a big boost for example. You don't have to go as far as routing manually. Sometimes the placer puts things like a blockram or multiplier in a bad place (look at the floorplanner). In a few occasions I locked a blockram or multiplier in a fixed position to get a design to meet timing constraints. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 151761
for this project, http://www.fpga4fun.com/10BASE-T.html what things need to be changed in order to make it work in spartan 3a? regards --------------------------------------- Posted through http://www.FPGARelated.comArticle: 151762
> for this project, http://www.fpga4fun.com/10BASE-T.html > what things need to be changed in order to make it work in spartan 3a? There isn't anything in the code that looks remotely model-specific, so you shouldn't need to do anything other than the standard things: - Correct pin constraints for your board - Generate correct clock. The example code assumes and requires a 20 MHz clock. JoelArticle: 151763
On May 15, 7:16=A0am, Brian Drummond <br...@shapes.demon.co.uk> wrote: > On Sun, 15 May 2011 08:47:21 +0200, Michael wrote: > > HI, > > > On 05/14/11 09:32 PM, Brian Drummond wrote: > >> On Sat, 14 May 2011 14:35:06 +0200, Michael wrote: > >> Don't expect 50-60% speed improvement from a different synthesis tool! > > For sure no, I was hoping that a change of synth would make say 10-15% > > then I would make it a go. > > > But, have you used any other synth tools lately? > > Mentor Leonardo (years ago!) but not lately. > I found my time better spent on improving the design, but YMMV. > > >> Look at re-architecting the design itself. > > This is where I expect to gain the remaining 30-40 %, but as I wrote I > > need to try both a tool change and recoding some parts. > > Do you have any specific reason for believing the improvement here is so > limited? > > >> There are some benefits to be had from floorplanning the speed-critica= l > >> sections, perhaps explore if PlanAhead can help you meet your targets. > > > Hmm, I have actually never exlored PlanAhead if that would help. Have > > you used it? > > Not PlanAhead but in the ISE 6.1/7.1 era I played extensively with the > earlier Floorplanner, now replaced by PlanAhead. It had serious problems > supporting hierarchical and reusable blocks, but... > > I could take a block that PARed at 80MHz and get 120MHz out of it with > careful floorplanning, and (working around said problems) reuse that > block multiple times with PAR placing less critical parts of the design. > However, above a certain level of congestion, PAR would route other > signals through my carefully floorplanned blocks, destroying some of the > additional performance. > > Now (1) I can't say how this gain transfers to PlanAhead, and (2) PAR > might get closer to optimal performance these days, but it's definitely > worth looking into as a source of improvement. > > - Brian PlanAhead is well worth a look. It won't affect synthesis results, but it will ensure map/par are used as efficiently as possible. Even without any floorplanning done at all, it can automatically try multiple 'strategies' to get the best performance out of the map/par tools. Floorplanning (for the little amount I had to do to achieve my targets) is easy, and it will also import previous implementations so you can see where your critical path was physically placed, and just floor-plan that bit, and then re-implement. So in that way it can offer quick turn-around with minimal up front work, if just a few paths are giving trouble.Article: 151764
Andrew Holme wrote: > "Mr.CRC" <crobcBOGUS@REMOVETHISsbcglobal.net> wrote in message > news:iqkvcv01c5r@news6.newsguy.com... >> assign a = ~cnt[1]; >> assign b = cnt[1] ^ cnt[0]; >> assign m = ~b & (cnt == 0 || cnt == MAX_CNT); >> // index pulse m is high >> // straddling max count and zero. Why the redundant '&' with ~b is >> // performed? I forget. Maybe this is unnecessary. >> endmodule > > > This module qep_sim will have glitches in the middle of the high pulse on > output b when cnt[1] changes picoseconds before cnt[0] as it can do, > depending on internal routing. Actually, on second thought, if the counter is synchronous, then I would expect it to be safe to perform combinatorics on the output. This is a classic approach with discrete logic, which works because even if there is process skew (or even sub ns delays due to actual paths on a discrete wired logic circuit with typical devices switching in the >=4ns range) between the individual bits, the resulting differences in timing are much shorter than gates of the same process can detect. Thus, the simple rule that if you want to perform combinatorial functions on the output of a counter, use a synchronous counter (where all outputs change *effectively* at the same time within the timescales that the gates can switch), and things will work out just fine. I have always observed this to be correct in practice. Where you would run into trouble, is if you do something silly like using a slow 4000 CMOS counter to feed a combinatorial comparator made out of fast HC or AC gates. Thus, unless the combinatorials in the FPGA can actually switch on a few ps glitch in the output data of the counter, then this is really not an issue. As a design principle though, what I suspect is that again, there is a paradigm shift going from the discrete logic world to the FPGA, where in the latter, everything is done synchronously. So, in order to make this synchronous, do I simply register the output of the combinatorial functions? -- _____________________ Mr.CRC crobcBOGUS@REMOVETHISsbcglobal.net SuSE 10.3 Linux 2.6.22.17Article: 151765
KJ wrote: > On May 14, 11:27 am, "Mr.CRC" <crobcBO...@REMOVETHISsbcglobal.net> > wrote: >> If there is a circuit which is to be clocked by an >> external source, and it is not going to interact with other process on >> different clocks, then why bother syncing this clock input to the 50MHz >> on-board clock? > > You wouldn't. The point of synchronizing to a clock is when you're > *changing* clock domains. > >> Ie, my qep_sim.v exists in its own clock domain, albeit >> there is still the mux to choose which external clock to use. >> > > The output of the clock mux is a new clock domain, different than > either of the two input clock domains. Thinking that the selected > input clock and the 'output of the mux clock' are the same clock > domain is a mistake that will come back to bite you. Ok, so then what we have here is that we need to input two different clocks, and use one or the other. Whichever one we use, after multiplexing is a unique clock domain. The question then is what is the proper way to multiplex clock sources, and once multiplexed, to distribute that clock properly? >> This also doesn't answer the question of why the behavior changes vs. >> input pin. >> > > Because sometimes you get 'lucky'. There are probably lots of things > (such as moving pins, hand routing, etc.) that you can do to appear to > 'fix' the problem. If you're lucky you'll find that none of these > things really works well and that you still occasionally get > glitches. If you're not lucky you won't find this out until much > later when it will get more and more difficult and expensive to fix if > you've deployed many of these boards. > > If you'd rather be smart than lucky you'll stop using gated internal > clocks and adopt synchronous design practices. Recall I said: "but I suspect if I simply move the ext_sim_clk to a different pin, the problem will go away. I wouldn't be satisfied with this however, as I wish to understand the real cause of the problem." You stated that once a clock is muxed, then it is a new clock domain. You also stated that one wouldn't bother syncing a clock unless changing clock domains. There is no data moving across clock domains here. The data would be generated in the post-mux counter. Are you trying to say that the only way to do this correctly is sample the two clocks with another clock??? What if they are of similar frequency to the available sampling clock? What if I don't want the sampling jitter? What if the result of the counter that is to be clocked by one of two different sources must remain in the same clock domain as the clock source outside the FPGA? Ok then, the mux becomes a problem. But in this case, the delay of a mux is insignificant. But the jitter of sampling might be significant. There might be a legitimate need to keep the counter synchronous with an external process. So the question remains quite simply: what is the proper way to multiplex clock sources, and once multiplexed, to distribute that clock properly? There are discussions on the Altera forum of resources in the Altera FPGAs for muxing clock sources and properly distributing them. So it is clear that the chip maker sees the need for being able to do this correctly. For ex: "Ripple and gated clocks: clock dividers, clock muxes, and other logic-driven clocks" http://www.alteraforum.com/forum/showthread.php?t=2388 I think my situation conforms with this guideline: Guideline #2: Have no synchronous data paths going to/from the derived clock domain Thus, this post seems to pertain: "Gated clocks: On/off gating and muxing of clocks in clock control blocks or logic" >> A more interesting question is then, is it possible to take a GP IO >> input pin, and internally buffer it onto an internal clock routing line? >> > > I may be an interesting question...but you'll get to the end line much > sooner if you use strictly synchronous practices and only cross clock > domains either with dual clock fifos or proper synchronization logic. > > Kevin Jennings What if the clock that I want to feed into a pin, which is not a GCLK, defines a clock domain? Then this is not crossing domains. Can a regular IO pin buffer onto a proper clock routing network? Thanks for input. -- _____________________ Mr.CRC crobcBOGUS@REMOVETHISsbcglobal.net SuSE 10.3 Linux 2.6.22.17Article: 151766
rickman wrote: >> Also, I wonder about the use of a once-registered asynchronous input >> signal. Shouldn't the sim_clk be registered at least twice before >> engaging in combinatorial functions? Ie, it seems that if ext_clk[0] >> waffles for a few extra ns due to metastability, then the pulse on >> "rising_edge" could be shorter than 20ns and not reliable. > > Are you using rising_edge as a pulse with a defined width or is it an > enable to the next FF? You can resolve metastability anywhere along > this chain, as long as you do it before the signal branches out to > more than one place. > > >> Wouldn't it make more sense to simply use: >> >> wire rising_edge = ext_clk[1] & ext_clk[0]; // ??? > > No, this does not detect an edge. This resolves metastability and > eliminates glitches, but you still need to detect the edge of the > clock signal. The idea of detecting the edge is to both bring the > signal into the clk50 domain and also create a one clock period wide > enable to use in place of a separate clock. > > >> In which case I think it is safe even employing the once-registered >> ext_clk[0] ? > > No, this doesn't even resolve metastability unless you provide more > slack time to the next FF. Ok, I am beginning to have my light bulb turn on slowly here. The clock enable concept is new to me, but I think I get it. By sampling my external clock and creating pulses in the clk50 domain, I can use those to enable the counter. The only thing I'm still unsure about is, that if these rising_edge pulses are generated by logic, then they are delayed somewhat from clk50. Do they enable count on the NEXT clk50 edge? (And then disappear a few ns after that clock edge?) Would it make more sense in this type of situation to sample with a 180 deg phase shifted ~clk50, so that the clock enable pulses would be centered on the clk50 counting edges? >> There is still an unresolved engineering principles question here >> though. Do FPGA logic designers ALWAYS sync asynchronous inputs to the >> internal clock? > > "Always" is a big statement. I nearly always pick one fast clock > domain as the "internal" clock and sync slow clocks to this fast one. > Each "external" clock becomes a clock enable internally. There are > times when I use the external clock directly, for example the serial > clock on an SPI port directly clocks the shift register in a recent > SPI design. Then I have lots of time to sync the parallel word to the > internal clock. But this could be done either way. Sometimes it > depends on the relative rate of the two clocks. The closer in speed > they are the harder it can be to fully analyze the timing. Yes, I see. And I also see how this becomes quite messy if the external clock is near the speed of the internal one. But only if data needs to cross between the two domains, right? >> If there is a circuit which is to be clocked by an >> external source, and it is not going to interact with other process on >> different clocks, then why bother syncing this clock input to the 50MHz >> on-board clock? Ie, my qep_sim.v exists in its own clock domain, albeit >> there is still the mux to choose which external clock to use. > > If it is completely independent as if it were being done on a separate > chip, then yes, there is no reason to sync it to the internal clock as > long as you can get the clock to a clock input and even that is not > essential. The tools have to do less work to make a clock on a clock > tree meet setup and hold times. Ok, so while I have learned something so far about how to sync external (slow) clocks to an internal fast clock, it is the case here that this qep_sim() is a unique clock domain, so should be able to be clocked by its external source directly. >> This also doesn't answer the question of why the behavior changes vs. >> input pin. > > I suspect that has to do with your clock signal. Does it have a slow > rise/fall time? I suspect a bit of noise is making it double clock. > When you route it differently (since it is not on a clock IO pin) the > glitch can get filtered out depending on how it is routed. It only > takes a very tiny glitch to cause this sort of double clocking and > such a tiny glitch can be filtered by the random routing. Putting it > on a global clock tree should make it fail more often. I have to probe it again Monday. I recall Friday that I was a bit surprised that it had a rounder rising edge near the upper level than I would have expected. However, I think it is still in the <200ns range. It originates from a TI ISO7220C, which specify 1ns output rise/fall. Good grief, that can't be right. I'ts slowed down a little with a resistor in there for various reasons related to power sequencing of the IO buffer panel, vs. the DSP that it usually feeds, or optionally the FPGA. I tried to find the min rise time spec in the Spartan 3E datasheet last night, and I could swear I found a place where it said 500ns, and now for the life of me I can't find it again in that hideously long document. I will look into this again with the scope. I'm almost sure it's not noise though, since a time magnification of the clock when a counting glitch occurs is perfectly smooth. An important fact is that the counting error always happens on a falling edge of this ext_sim_clk, not at random times. So it's not picking up junk from other traces which may carry asynchronous signals, of which there are a few. >> I have gathered that when clocks are to be brought in to the FPGA, it is >> highly recommended to use a GCLK IO pin, so the signal may be buffered >> onto a global clock routing line. I have to see if I can rearrange my >> IOs to get these external inputs onto GCLK IOs, but there are two of >> them and the NEXYS2 isn't very liberal about providing GCLKs on the pin >> headers. Some other GCLKs are available on another connector, but I >> don't yet have the mating for that. > > Don't try to fix a problem if you don't understand the cause. Why > would a GLK IO pin eliminate your problem? Oh, I don't have any intention of fixing it until I have understood it (I stated this in the OP)! >> Of course, when muxing external clock sources, if there are a lot of >> them, one could eat into the supply of GCLKs quickly, so this is >> undesirable. > > Bingo! That is a big reason for treating slow clocks as clock enables > on an internal clock. Well in this case, it also gets muxed. So it would be a waste of GCLK inputs if it gets fed through logic and becomes a "derived clock" anyway. >> A more interesting question is then, is it possible to take a GP IO >> input pin, and internally buffer it onto an internal clock routing line? > > Isn't that what is already happening in your case? I have no idea at this point until I learn more about constraints and how to interpret the hundreds of pages of jibberish that the tools report when I make my bit file. As I mentioned in another post, there seems to be considerable discussion on the Altera forum about using constraints to control how a clock is distributed. There is also a discussion of how muxing clocks can be dangerous. I am very suspicous that this might be the real cause of my problem, rather than a signal integrity issue (I'm pretty good with signal integrity): "Gated clocks: On/off gating and muxing of clocks in clock control blocks or logic" http://www.alteraforum.com/forum/showpost.php?p=8506&postcount=7 I have to learn more about how these things are managed on the Xilinx device as well. >> Thanks for input and clarification. > > Let us know what you find. It is hard to analyze problems like this > without doing tests. I may be completely off base in this case. > > Rick What do you make of the test that I did where I took a copy of the muxed clock, and routed it back outside, then the glitches disappeared? Since this was not perturbing the ext_sim_clk input path, and yet the problem disappeared, it argues strongly that the glitches are originating internally, possibly in the mux, where perhaps a change in loading by adding the new output path makes the glitches go away. Thanks very much for your feedback! -- _____________________ Mr.CRC crobcBOGUS@REMOVETHISsbcglobal.net SuSE 10.3 Linux 2.6.22.17Article: 151767
On May 15, 2:40=A0pm, "Mr.CRC" <crobcBO...@REMOVETHISsbcglobal.net> wrote: > KJ wrote: > > The output of the clock mux is a new clock domain, different than > > either of the two input clock domains. =A0Thinking that the selected > > input clock and the 'output of the mux clock' are the same clock > > domain is a mistake that will come back to bite you. > > Ok, so then what we have here is that we need to input two different > clocks, and use one or the other. =A0 1. What exactly is the 'need'? 2. What exactly needs to be clocked? 3. What exactly are you sampling with these clocks that really does need to be sampled with those clocks? If you step back a bit, I believe you'll find (at least based on what you've posted here) are the following answers: 1. Nothing 2. A counter 3. Nothing > Whichever one we use, after > multiplexing is a unique clock domain. =A0The question then is what is th= e > proper way to multiplex clock sources, and once multiplexed, to > distribute that clock properly? > In this case, the solution is not to clock anything with your muxed 'clocks' since there is nothing that actually needs to be clocked with those signals. Instead you should mux those input 'clocks' to create a logic signal that you then synchronize to your FPGA's clock (I'm assuming here that there is some clock used for clocking logic in the FPGA that has nothing to do with these input clocks...maybe that's not what you have, will get to that later). Now takes this this muxed logic signal, synchronize it and delay it and then simply look for a clock cycle of '0' followed by a clock cycle of '1' to create a clock enable for the counter. The counter is clocked by the FPGA's clock. If there is no other FPGA clock as I assumed, then more info would be needed about just what you have. Based on what you've described though, the only situation where you would have to actually mux a clock and use it as a muxed clock would be if those two input clocks need to be selected AND the unselected clock is not guaranteed to be there. > >> This also doesn't answer the question of why the behavior changes vs. > >> input pin. > > > Because sometimes you get 'lucky'. =A0There are probably lots of things > > (such as moving pins, hand routing, etc.) that you can do to appear to > > 'fix' the problem. =A0If you're lucky you'll find that none of these > > things really works well and that you still occasionally get > > glitches. =A0If you're not lucky you won't find this out until much > > later when it will get more and more difficult and expensive to fix if > > you've deployed many of these boards. > > > If you'd rather be smart than lucky you'll stop using gated internal > > clocks and adopt synchronous design practices. > > Recall I said: "but I suspect if I simply move the ext_sim_clk to a > different pin, the problem will go away. =A0I wouldn't be satisfied with > this however, as I wish to understand the real cause of the problem." > Find the documentation that guarantees that the device, when generating an internally generated clock signal, will distribute that clock to arrive at each destination flop simultaneously enough to guarantee that any logic input signal to that flop will not violate the setup/hold window. Over all temperature ranges? Really? Or is the guarantee only that an input clock pin (or PLL/DLL output) can be freely distributed anywhere about the device and be guaranteed that any logic input will meet setup/hold times? (Hint: That is likely the thing that is guaranteed). > You stated that once a clock is muxed, then it is a new clock domain. > You also stated that one wouldn't bother syncing a clock unless changing > clock domains. =A0There is no data moving across clock domains here. =A0T= he > data would be generated in the post-mux counter. > Right, so there is no need in your case to use either of your input clock signals as a signals that clocks anything in your device. All you're doing is looking for edges on the muxed signal and when you find it, use that as the clock enable to the counter (after having synchronized that muxed signal). > Are you trying to say that the only way to do this correctly is sample > the two clocks with another clock??? > Not quite. What I'm saying is that if you have another clock that will always be running and is fast enough compare with your two input clocks, then I'm saying that this is the best way in an FPGA. > What if they are of similar frequency to the available sampling clock? > What if I don't want the sampling jitter? =A0 Then the clock mux should be external to the FPGA where you can guarantee better defined performance. > What if the result of the > counter that is to be clocked by one of two different sources must > remain in the same clock domain as the clock source outside the FPGA? Since the input to and output from a mux are not the same, this clock mux (wherever it is located) would define different clock domains...the counter would not be operating in the same clock domain. However, what you're really trying to say, but not expressing, is that there might be a latency requirement from the rising edge of the input clocks to the mux until the counter output is valid. That stated requirement, by itself, does *not* imply that there must be a clock mux. Assuming for the moment that the mux is external, than this simply says you have a Tco requirement on the counter relative to the FPGA's input clock. To calculate the required Tco for the FPGA, you would have to subtract off the max prop delay through the external mux. > Ok then, the mux becomes a problem. =A0But in this case, the delay of a > mux is insignificant. =A0But the jitter of sampling might be significant. You're not actually sampling anything here. > =A0There might be a legitimate need to keep the counter synchronous with > an external process. > When you come across that need, you'll have a different description of the problem at hand. > So the question remains quite simply: =A0what is the proper way to > multiplex clock sources, and once multiplexed, to distribute that clock > properly? > And there isn't a single answer. The simplest, most portable answer is the one that has been discussed here which is to use the muxed clock not as something that actually clocks anything but instead enables clocked logic. This has situations though where it is not appropriate, namely where the free running clock is not significantly faster than the clocks being muxed. Another approach would mux the clocks external to the FPGA as I mentioned here. This is appropriate in some cases. Another approach is to input the two clocks into a PLL/DLL in the device that allows for multiple input clocks to be muxed together. Here the FPGA has dedicated resources with known delays that enable this solution to work. Limits you to using devices that have this ability. Another approach is to simply run multiple sets of logic in parallel each clock clocking its own set of logic. The mux then is on the output. Takes more logic, but sometimes that is an acceptable way. Another approach is to mux the signals in the FPGA and generate that as an output signal. Feed that back on a real clock input pin to the FPGA. There are other approaches...the point is that each design situation can present unique opportunities to take advantage of specific situations. > There are discussions on the Altera forum of resources in the Altera > FPGAs for muxing clock sources and properly distributing them. =A0So it i= s > clear that the chip maker sees the need for being able to do this correct= ly. > The Altera forum is open to posters from all over the world (as is comp.arch.fpga)...don't believe everything you read on the internet. One would also question the validity of using any technique that might happen to take advantage of an Altera specific feature on a device from Xilinx. If the technique is generic then it should be applicable. > For ex: > "Ripple and gated clocks: clock dividers, clock muxes, and other > logic-driven clocks"http://www.alteraforum.com/forum/showthread.php?t=3D2= 388 > > I think my situation conforms with this guideline: > That post is written by 'Brad' who has a status of 'guest'. Do you have some specific reason for believing everything that Brad has to say? One person who has earned a decent rep thought the post was good, maybe it is OK. But what exactly in your design is requiring you to actually use a generated clock? > Guideline #2: Have no synchronous data paths going to/from the derived > clock domain > > Thus, this post seems to pertain: > Which is immediately after... #1: Do not use ripple or gated clocks; use clock enables or PLLs instead. > > What if the clock that I want to feed into a pin, which is not a GCLK, > defines a clock domain? =A0Then this is not crossing domains. =A0Can a > regular IO pin buffer onto a proper clock routing network? > You're hung up a bit on 'clock domain' as a term. You need to focus instead on delays. How long does it take to get from an external pin to a clock input of a flop for example? Do you care about the delay? What is the skew between multiple flops? Are there any special requirements or can those flops be placed anywhere? Kevin JenningsArticle: 151768
Hi, I am using xilinx 12.3 for synthesis and implementation of my design and i am facing 2 problems. I don't know if anyone else has faced them or not. Problem 1: I am using xilinx simple dual port block ram in my design generated by xilinx 12.3. The problem is its random behavior on reading. Sometimes it gives output 1 clock cycle after the address has been changed.And sometimes it gives output on the same clock when the address is changed. I designed my logic according to the behavior of data coming out after 1 clock cycle of address. And every time the other case happens, my data coming out of RAM becomes invalid. I didn't choose the pipelined output option or anything that could put a flip flop on the output stage. But still data was coming out 1 clock cycle delayed so by watching this behavior i designed my logic, so kindly tell me what to do, maybe there's something i am missing or something i need to know to make it work. Actually i have 2 RAMs ,byte wide each. The incoming data is 2bytes wide so i write 1 byte to RAM1 and 2nd byte to RAM2. And i read in the same manner i.e. one byte from RAM1 and 2nd byte from RAM2.And i update my read address after i have read the data from RAM2. Problem 2: I am using xilinx FIFO generated by xilinx 12.3 in my design and i cannot read from it unless i have written at least 8,9 bytes to it. Even if i give it a read signal, it is ignored and empty signal stays high even though i have written some bytes in to it. As soon as 8 bytes have been written, the empty signal goes low and i can read the data then. Is this the proper behavior or am i the only one facing it? Kindly help me with this thing. Thanks a lot. Regards --------------------------------------- Posted through http://www.FPGARelated.comArticle: 151769
> In this case, the solution is not to clock anything with your muxed > 'clocks' since there is nothing that actually needs to be clocked with > those signals. Instead you should mux those input 'clocks' to create > a logic signal that you then synchronize to your FPGA's clock I would probably take it a step further and synchronise the two 'clocks' to the FPGA clock at the IO then select which of the two synchronised inputs is used as the enable for the counter. Generalising.... Mr CRC, FPGAs and the tools are designed to guarantee that the output of one register clocked with one clock will get to the input of any other register clocked with the same clock (as long as the build meets timing). This is the beauty of the devices, you don't need to worry about timing, just functionality. Once you start introducing asynchronous clock transfers guaranteeing what happens between them is difficult to constrain, and for the tools to analyse. This is what needs to be carefully handled in your design. It is easiest to design, constrain, guarantee meeting timing and so get guaranteed functional devices if you keep the number of clocks to a minimum. Preferably 1 (though this is rarely possible). Nial.Article: 151770
Problem 1 questions: How did you discover this behavior? Simulation? Chipscope? If chipscope, does it work in functional simulation? If so, can you describe difference between simulation stimulus and chipscope stimulus? Are you using separate clocks to write/read data to/from dpram? Does your design pass static timing analysis for all clock domains? What is the exact relationship between the write cycles and read cycles? Did you use coregen to create the dpram? If so, what latency does it say your dpram will have? It will alter this depending on if you select primitive/core output regs. Problem 2 questions: Maybe you have unintentionally configured and are using a programmable almost empty flag? - JohnArticle: 151771
On May 14, 3:18=A0am, Michael <michael_laaja...@yahoo.com> wrote: > > My question was if you or anyone else have any experience with the > latest Xilinx and a third party syntheses tool! > > /michael I am qualified to answer your question. I am seeing clock->clock gains in the 3~5% range changing synthesizers. Initial reports show gains larger than that, but those gains shrink when the timing constraints are applied properly. Brian Drummond <=3D what he said! Re-architect the design. Shrink the clock regions. Play with manual placement. In that order. The Xilinx tool has some issues; notably it does not understand that modern (deep sub-micron) routes are wire-load limited, not gate delay limited. That, and it has no freaking clue how to distribute re- timing registers. RKArticle: 151772
Thank you, everyone, for your helpful replies. Unfortunately the funding for this project got pulled yesterday. But at least I've learnt something from this. - AlexanderArticle: 151773
Hi: Today I took scope shots of a clock input to my Xilinx Spartan 3e, Digilent NEXYS2 board. The clock goes to a counter, simulating a quadrature encoder, as explained in post "Counter clocks on both edges sometimes, but not when different IO pin is used" on 5-13-2011. I have discovered that I'm dealing with a different animal here than even the fastest logic chips I've grown comfortable with, the AC family. First is the input to the NEXYS2 IO connector pin, driven by a TI ISO7240c chip, with about a 150 series resistor. This shows an incidence where the counter incorrectly counted on the falling edge: http://web.newsguy.com/crobcng/spartan3e/scope_11.png The falling edge which caused the glitch: http://web.newsguy.com/crobcng/spartan3e/scope_12.png At this point I was thinking, "there is no reason for this to be a problem." As any discrete logic chip would never glitch with this. Nonetheless, the evidence is that internally the counter is seeing a rising edge here, so there must be a brief upward wiggle internally. How to see this? I can't really. The best I can do is take a copy of the internal signal, and spit it back out another IO port. Here is where things get weird. Depending on which pins are chosen, it is possible that the glitches will go away when a copy is sent out an IO port. An important additional clue was the fact that an adjacent pin to the clock input, when changed from unconfigured (input) to output, even if just a static logic level was output, caused the glitching to go away. More on that later. Here is the scope looking at the output from the FPGA, of a copy of the internal clock, again captured on an offending falling edge causing an incorrect count (note this just looks the same as scope_12.png above: http://web.newsguy.com/crobcng/spartan3e/scope_13.png But when zoomed in, there is the slightest wiggle present: http://web.newsguy.com/crobcng/spartan3e/scope_14.png Now this is a 500MHz scope with a 500MHz probe, and very short (1.5cm) ground lead, so this is a good probing setup. That little wiggle is nearly a Ghz! Due to at least -6dB of attenuation from the scope + probe, the actual wiggle is probably twice or more than the amplitude shown, which is barely anything. Now this is of course NOT what the internal signal looks like, of course, because it had to go through an output buffer. Also, the choice of LVCMOS 3.3V makes this perhaps the slowest output possible. But it seems like the output buffer is trying to tell us something, about what the internal signal looks like. It has a friggin' glitch! I also zoomed in on several adjacent falling edges, ones which did not cause a counter glitch. These have at most a "shelf" at the same level, but no slope reversal. Most have just an inflection. There is a pattern here. Finally, I replaced the driver of the input pin from the relatively high impedance source to a terminated 50 ohm cable with 10ns edges coming directly from a generator, and the glitches stopped. This is consistent with the fact that the behavior changes in relation to the change in impedance of a pin adjacent to the input pin. This is fascinating. I have to wrap my head around the fact that things can be happening inside the chip at the near GHz rate, so the magnitude of the signal integrity requirement stringency is about an order of magnitude more demanding than I'm used to. I would like to scope this again with my 1GHz scope (the one I thought I'd only ever need for my optical parametric oscillator work), and see if also I can get a faster, lower voltage signaling standard selected. I'm not sure if the NEXYS2 board will let that happen. We'll see. I'm also curious to see what will happen if the edge time is slowed down, but the drive impedance is still low. Fortunately my generator has adjustable slew rates, so I can check this out too. Well at least now I know what is really going on. -- _____________________ Mr.CRC crobcBOGUS@REMOVETHISsbcglobal.net SuSE 10.3 Linux 2.6.22.17Article: 151774
On May 13, 2:42=A0pm, Michael <michael_laaja...@yahoo.com> wrote: > Hi, > > I have been using Xilins XST for a while and have come to a performance > problem which leads me to think of if there is any better syntheses like > Synopsys or other. > > The device is a Spartan3 4000 an I use Xilinx 13.1 since a couple weeks > ago after a upgrade from 9.2 > > Anyone that can share some experience of syntheses? > > /michael Assuming that webpack supports your device you might do better buying several PCs and creating a linux server farm. Then you can automatically synthesize overnight with many P&R seeds. We do this, but we have 10+ firmware guys sending builds to the farm all the time so its obviously cost effective for us.
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