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
Looks to me as if you have the wrong package set in your project settings. MikeArticle: 158376
Not knowing your exact requirements, the simplest I can see would be a running average of a large number of samples, and subtract that. E.g total = total + sample(n) - sample(n-2048), output = sample-total/2048. The division would be a bit shift, and the 2k of samples could be held in a ram block. It is pretty trivial to show that DC would be blocked, and signals at f/2048 will not be attenuated (as the average would be zero). It would also be very fast and have minimal latency, however it would introduce some phase distortion as it isn't symetrical. If that is an issue for your application, then a way around it would be to total over 2047 samples, and subtract the total from 2047*sample(n-1024), then divide by 2048 (once again this can be implemented with addition, subtraction and bitshifts). The output will be slightly attenuated (by 1/2048), but no phase distortion would occur. It will also have a latency of 1024 cycles or so. MikeArticle: 158377
On Sunday, October 25, 2015 at 11:41:15 AM UTC+6, glen herrmannsfeldt wrote: > abirov@gmail.com wrote: > > Dear all first of all want thanx to everyone who belong to this > > forum and give help to each other. > > > I checked ML405's schematic that pins, and are exist, > > i used advice of Aurelian Lazarut (cleaning project files) > > but no success. It cannot be mapped. > > > Could someone help me with this problem? > > > Here is Errors. > > > ERROR:MapLib:30 - LOC constraint M19 on SW1 is invalid: No such site on the > > device. To bypass this error set the environment variable 'XIL_MAP_LOCWARN'. > > (snip of more similar messages) > > My guess is that you have the wrong package set, and the pins are > numbered different than the right package. > > -- glen Only one package available FF672xxxxxxxArticle: 158378
On Sunday, October 25, 2015 at 12:39:11 PM UTC+6, Mike Field wrote: > Looks to me as if you have the wrong package set in your project settings. > > Mike There is only one package FF672 in design properties no any other, so i used it. here is my UCF file : NET "SW1" LOC = "M19" ; NET "SW2" LOC = "P16" ; NET "SW3" LOC = "M11" ; NET "SW4" LOC = "N11" ; NET "SW5" LOC = "M10" ; NET "SW6" LOC = "M9" ; NET "SW7" LOC = "N8" ; NET "SW8" LOC = "N7" ; NET "SW1" CLOCK_DEDICATED_ROUTE = FALSE; NET "SW2" CLOCK_DEDICATED_ROUTE = FALSE; NET "SW3" CLOCK_DEDICATED_ROUTE = FALSE; NET "SW4" CLOCK_DEDICATED_ROUTE = FALSE; NET "SW5" CLOCK_DEDICATED_ROUTE = FALSE; NET "SW6" CLOCK_DEDICATED_ROUTE = FALSE; NET "SW7" CLOCK_DEDICATED_ROUTE = FALSE; NET "SW8" CLOCK_DEDICATED_ROUTE = FALSE; NET "pushE" LOC = "m6" ; NET "pushN" LOC = "g11" ; NET "pushS" LOC = "l10" ; NET "pushW" LOC = "k8" ; ####################### VGA ###################### NET "vga_b_out<0>" LOC = "P10" ; NET "vga_b_out<1>" LOC = "P11" ; NET "vga_b_out<2>" LOC = "R8" ; NET "vga_b_out<3>" LOC = "f4" ; NET "vga_b_out<4>" LOC = "j4" ; NET "vga_b_out<5>" LOC = "g9" ; NET "vga_b_out<6>" LOC = "j5" ; NET "vga_b_out<7>" LOC = "h3" ; #NET "vga_blank_n" LOC = "M24" ; NET "vga_clk_out" LOC = "AC7" ; NET "vga_g_out<0>" LOC = "N9" ; NET "vga_g_out<1>" LOC = "N6" ; NET "vga_g_out<2>" LOC = "p6" ; NET "vga_g_out<3>" LOC = "j3" ; NET "vga_g_out<4>" LOC = "k7" ; NET "vga_g_out<5>" LOC = "k3" ; NET "vga_g_out<6>" LOC = "g10" ; NET "vga_g_out<7>" LOC = "k6" ; NET "VGA_HSYNC" LOC = "C3" ; #NET "vga_psave_n" LOC = "M25" ; NET "vga_r_out<0>" LOC = "R6" ; NET "vga_r_out<1>" LOC = "R7" ; NET "vga_r_out<2>" LOC = "P9" ; NET "vga_r_out<3>" LOC = "f3" ; NET "vga_r_out<4>" LOC = "h7" ; NET "vga_r_out<5>" LOC = "e3" ; NET "vga_r_out<6>" LOC = "g5" ; NET "vga_r_out<7>" LOC = "g10" ; #NET "vga_sync_n" LOC = "L23" ; NET "VGA_VSYNC" LOC = "d4" ; ########### CAMERA ########### NET "camRST_i" LOC = "w23";# | CLOCK_DEDICATED_ROUTE = FALSE; #36 NET "camFRAMEVALID" LOC = "v24";# | CLOCK_DEDICATED_ROUTE = FALSE; #38 NET "camLINEVALID" LOC = "y23";# | CLOCK_DEDICATED_ROUTE = FALSE; #40 NET "camPIXCLK" LOC = "ad20" |CLOCK_DEDICATED_ROUTE = FALSE; #42 NET "camDATA<4>" LOC = "ad21" ;# | CLOCK_DEDICATED_ROUTE = FALSE; #44 NET "camDATA<5>" LOC = "ac21" ;# | CLOCK_DEDICATED_ROUTE = FALSE; #46 NET "camDATA<6>" LOC = "ad19" ;# | CLOCK_DEDICATED_ROUTE = FALSE; #48 NET "camDATA<7>" LOC = "y17";# | CLOCK_DEDICATED_ROUTE = FALSE; #50 NET "camDATA<8>" LOC = "ad18";# | CLOCK_DEDICATED_ROUTE = FALSE; #52 NET "camDATA<9>" LOC = "aa17" ;# | CLOCK_DEDICATED_ROUTE = FALSE; #54 NET "camDATA<10>" LOC = "ac17" ;# | CLOCK_DEDICATED_ROUTE = FALSE; #56 NET "camDATA<11>" LOC = "ab17";# | CLOCK_DEDICATED_ROUTE = FALSE; #58 NET "camEXPOSURE" LOC = "ab16";# | CLOCK_DEDICATED_ROUTE = FALSE; #60 NET "camOE" LOC = "ab15";# | CLOCK_DEDICATED_ROUTE = FALSE; #62 NET "camCLKIN" LOC = "aa15";# | CLOCK_DEDICATED_ROUTE = FALSE; #64 NET "camDATA<4>" IOSTANDARD = "LVCMOS33"; NET "camDATA<5>" IOSTANDARD = "LVCMOS33"; NET "camDATA<6>" IOSTANDARD = "LVCMOS33"; NET "camDATA<7>" IOSTANDARD = "LVCMOS33"; NET "camDATA<8>" IOSTANDARD = "LVCMOS33"; NET "camDATA<9>" IOSTANDARD = "LVCMOS33"; NET "camDATA<10>" IOSTANDARD = "LVCMOS33"; NET "camDATA<11>" IOSTANDARD = "LVCMOS33"; NET "camEXPOSURE" IOSTANDARD = "LVCMOS33"; NET "camFRAMEVALID" IOSTANDARD = "LVCMOS33"; NET "camLINEVALID" IOSTANDARD = "LVCMOS33"; NET "camRST_i" IOSTANDARD = "LVCMOS33"; NET "camOE" IOSTANDARD = "LVCMOS33"; NET "camPIXCLK" IOSTANDARD = "LVCMOS33"; NET "camCLKIN" IOSTANDARD = "LVCMOS33";Article: 158379
On Sunday, October 25, 2015 at 11:41:15 AM UTC+6, glen herrmannsfeldt wrote: > abirov@gmail.com wrote: > > Dear all first of all want thanx to everyone who belong to this > > forum and give help to each other. > > > I checked ML405's schematic that pins, and are exist, > > i used advice of Aurelian Lazarut (cleaning project files) > > but no success. It cannot be mapped. > > > Could someone help me with this problem? > > > Here is Errors. > > > ERROR:MapLib:30 - LOC constraint M19 on SW1 is invalid: No such site on the > > device. To bypass this error set the environment variable 'XIL_MAP_LOCWARN'. > > (snip of more similar messages) > > My guess is that you have the wrong package set, and the pins are > numbered different than the right package. > > -- glen I created two topics one is this and second with more messages in https://groups.google.com/forum/#!topic/comp.arch.fpga/wu1bXFMvW7I please look at it. thanx for advanceArticle: 158380
On Sunday, October 25, 2015 at 1:25:15 PM UTC+6, abi...@gmail.com wrote: > On Sunday, October 25, 2015 at 12:39:11 PM UTC+6, Mike Field wrote: > > Looks to me as if you have the wrong package set in your project settings. > > > > Mike > > There is only one package FF672 in design properties no any other, so i used it. > > here is my UCF file : > > NET "SW1" LOC = "M19" ; > NET "SW2" LOC = "P16" ; > NET "SW3" LOC = "M11" ; Partially solved. used link http://www.edaboard.com/thread11331.html But appear next error : ERROR:Pack:2811 - Directed packing was unable to obey the user design constraints (LOC=G10) which requires the combination of the symbols listed below to be packed into a single IOB component.Article: 158381
On Sunday, October 25, 2015 at 3:05:09 PM UTC+6, abi...@gmail.com wrote: > On Sunday, October 25, 2015 at 1:25:15 PM UTC+6, abi...@gmail.com wrote: > > On Sunday, October 25, 2015 at 12:39:11 PM UTC+6, Mike Field wrote: > > > Looks to me as if you have the wrong package set in your project settings. > > > > > > Mike > > > > There is only one package FF672 in design properties no any other, so i used it. > > > > here is my UCF file : > > > > NET "SW1" LOC = "M19" ; > > NET "SW2" LOC = "P16" ; > > NET "SW3" LOC = "M11" ; > > Partially solved. used link http://www.edaboard.com/thread11331.html > > But appear next error : > > ERROR:Pack:2811 - Directed packing was unable to obey the user design > constraints (LOC=G10) which requires the combination of the symbols listed > below to be packed into a single IOB component. Solved http://www.xilinx.com/support/answers/36343.htmlArticle: 158382
>>I've got trouble thinking how the GSR could be used for any useful >thing >by the designer. The trouble with the GSR is that it's >>removal edge is slow, and asynchronous to everything. So flops may >>reset fine with this signal, but coming out of reset, the state's >>still unknown. The parts of a design that can make reliable use of >>this, is a rare exception,not the rule, IMHO. >> > True. Altera (possibly others) do not guarantee powerup state. GSR can work in principle but vendors cannot guarantee how first edge of user clock is going to be relative to GSR release. So internally generated reset wouldn't work either as it will depend on powerup states. They always advise of having external reliable reset source. Kaz --------------------------------------- Posted through http://www.FPGARelated.comArticle: 158383
Gabor Szakacs wrote: > > If you want another old FPGA with internal tristate that is still in > production, check out Xilinx Spartan 2. It's also 5V tolerant... > These were officially discontinued some years back, but some big customers must have squealed VERY loudly! Digi-key even has stock of straight Spartan 2, but no stock or prices on Spartan 2E, which I did use in a product. I've moved on the Spartan 3A, which works nicely, and as long as they keep making those, they are a VERY good price for an FPGA. Spartan 2 and 2E have not been supported by their tools in a long time. I think Ise 10.1 is the last to support them. Fortunately, Xilinx does make their legacy tools available! JonArticle: 158384
On 23/10/15 20:55, Kevin Neilson wrote: > David, I like your explanation of mapping the field elements to > something abstract, like 0, 1, a, b, c, d, e, f. I've only seen one > textbook that mentioned something like this (it used Greek letters) > and I found it very helpful to realize that the field elements are > only arbitrarily *mapped* to integers and are not equivalent to > them. For non-algebraists, the use of numbers and "addition" and "multiplication" in field theory can be very confusing - "normal" people are too used to identities such as "two times x equals x plus x" that have no equivalent in fields such as GF(2^n). Using letters or other symbols helps make things clear. > > I don't use ROMs for field multiplication. A GF(2048) multiplier > takes about 64 6-input LUTs, as I recall, with about 3 levels of > logic. A fixed multiplier (multiplying by a constant) is more like > 20 LUTs. I use ROMs for division (find the reciprocal), cubing, etc. > If you use ROMs for multiplication it induces a lot of latency, > because you have 2-3 cycles for each blockRAM, and you have to do a > log and antilog lookup, so you can end up with 5+ cycles of latency. > Kevin > There's always a balance between throughput, latency and resource usage, depending on your requirements. My experience with these is in software rather than FPGA, where the balances are a little different.Article: 158385
Jon Elson wrote: > Gabor Szakacs wrote: > > >> If you want another old FPGA with internal tristate that is still in >> production, check out Xilinx Spartan 2. It's also 5V tolerant... >> > These were officially discontinued some years back, but some big customers > must have squealed VERY loudly! Digi-key even has stock of straight Spartan > 2, but no stock or prices on Spartan 2E, which I did use in a product. > I've moved on the Spartan 3A, which works nicely, and as long as they keep > making those, they are a VERY good price for an FPGA. > > Spartan 2 and 2E have not been supported by their tools in a long time. I > think Ise 10.1 is the last to support them. Fortunately, Xilinx does make > their legacy tools available! > > Jon EOL was announced for Spartan-2 some years back and then it was retracted. Spartan 2E is no longer manufactured. My guess is that it was easier to migrate from 2E to newer parts since 2E was already not 5V tolerant. In any case, Xilinx is generally happy to continue to supply old parts as long as there is enough demand and as long as the fab partners still have the process used to build the parts. Xilinx has never migrated an existing part to a different process node, and probably never will. -- GaborArticle: 158386
>=20 > For non-algebraists, the use of numbers and "addition" and > "multiplication" in field theory can be very confusing - "normal" people > are too used to identities such as "two times x equals x plus x" that > have no equivalent in fields such as GF(2^n). Using letters or other > symbols helps make things clear. >=20 It *is* confusing. If x is an element of a field, then (x+1)^2 =3D x^2+2x+= 1, but the '2' in '2x' isn't the '2' from the field (i.e., alpha^1); it's t= he regular integer 2. This was confusing to me initially. It just makes m= ore sense to write 'x+x' instead of '2x' (which is 0, of course, if the fie= ld is Gf(2^n)).Article: 158387
GaborSzakacs wrote: Xilinx > has never migrated an existing part to a different process node, and > probably never will. > The engineering of the LUTs is pretty difficult, and probably requires a number of prototypes to get all the paths time-equalized so that under all cases the LUT is glitchless. Also, getting the skew-free clock lines just right is probably difficult. if they scaled the chip, the timing simulations would all be off. So, it seems to me that scaling the chip would be essentially the same effort as designing a whole new chip from scratch. I think this is where FPGAs are just a little bit different from typical logic parts. JonArticle: 158388
On 10/26/2015 11:49 PM, Jon Elson wrote: > GaborSzakacs wrote: > > Xilinx >> has never migrated an existing part to a different process node, and >> probably never will. >> > The engineering of the LUTs is pretty difficult, and probably requires a > number of prototypes to get all the paths time-equalized so that under all > cases the LUT is glitchless. Also, getting the skew-free clock lines just > right is probably difficult. if they scaled the chip, the timing > simulations would all be off. I've never heard anyone say LUTs are glitch free because they are timing controlled. They are glitchless because they use pass transistor switches rather than gates for the mux. But I can't say I am knowledgeable about this. I just recall the description by the Xilinx guys who used to post here and they didn't talk about balancing timing in the LUTs. > So, it seems to me that scaling the chip would be essentially the same > effort as designing a whole new chip from scratch. I think this is where > FPGAs are just a little bit different from typical logic parts. I won't argue that this isn't true for the newer generations. I don't know it is for the same reasons. -- RickArticle: 158389
rickman <gnuarm@gmail.com> wrote: > On 10/26/2015 11:49 PM, Jon Elson wrote: (snip) >> The engineering of the LUTs is pretty difficult, and probably requires a >> number of prototypes to get all the paths time-equalized so that under all >> cases the LUT is glitchless. Also, getting the skew-free clock lines just >> right is probably difficult. if they scaled the chip, the timing >> simulations would all be off. > I've never heard anyone say LUTs are glitch free because they are timing > controlled. They are glitchless because they use pass transistor > switches rather than gates for the mux. But I can't say I am > knowledgeable about this. I just recall the description by the Xilinx > guys who used to post here and they didn't talk about balancing timing > in the LUTs. Yes, but you have to time the pass transistors right. Well, mostly you have to be sure not to go into any other state on the way to the right one. >> So, it seems to me that scaling the chip would be essentially the same >> effort as designing a whole new chip from scratch. I think this is where >> FPGAs are just a little bit different from typical logic parts. > I won't argue that this isn't true for the newer generations. > I don't know it is for the same reasons. Seems to me that retiming an existing design has to be easier than completely designing a new one, but maybe not all that much easier. -- glenArticle: 158390
On 10/27/2015 2:17 PM, glen herrmannsfeldt wrote: > rickman <gnuarm@gmail.com> wrote: >> On 10/26/2015 11:49 PM, Jon Elson wrote: > > (snip) >>> The engineering of the LUTs is pretty difficult, and probably requires a >>> number of prototypes to get all the paths time-equalized so that under all >>> cases the LUT is glitchless. Also, getting the skew-free clock lines just >>> right is probably difficult. if they scaled the chip, the timing >>> simulations would all be off. > >> I've never heard anyone say LUTs are glitch free because they are timing >> controlled. They are glitchless because they use pass transistor >> switches rather than gates for the mux. But I can't say I am >> knowledgeable about this. I just recall the description by the Xilinx >> guys who used to post here and they didn't talk about balancing timing >> in the LUTs. > > Yes, but you have to time the pass transistors right. > > Well, mostly you have to be sure not to go into any other state > on the way to the right one. I believe this only requires that the switching time for on time is longer than the off time. Then none of the pass transistors short different value memory cells together and invalid states and glitches are prevented, just a smooth transition between states. >>> So, it seems to me that scaling the chip would be essentially the same >>> effort as designing a whole new chip from scratch. I think this is where >>> FPGAs are just a little bit different from typical logic parts. > >> I won't argue that this isn't true for the newer generations. >> I don't know it is for the same reasons. > > Seems to me that retiming an existing design has to be easier than > completely designing a new one, but maybe not all that much easier. I believe there is a *lot* of footwork that goes into designing the logic cells for a new process if you want optimum results. That is where the work is and where the risk of respin is. The logical structure is fairly cut and dried. Porting a logic cell design to a new process should be a lot less work if you are not trying to optimize it. The question is, why would anyone want to port an older generation FPGA architecture to a new process when they are already designing a new family? The only reason would be to save customers the trouble of porting their designs to the new family. This would also require compatible pin outs which seem to be anathema in the FPGA world unlike the MCU world where they try very hard to share as much commonality in pinouts as possible. I would really like to see an MCU maker come out with FPGA enabled products. I know the bulk of the work would be in ramping up the FPGA side development software. Patents would not be a serious issue as most of the basic ones have run out. A low end FPGA/CPU design wouldn't need to be state of the art as most designs don't push the envelope for FPGAs. Mostly designers just want something that works. Cypress has some devices with "configurable" logic blocks, but they are more like programmable I/O devices than they are generic logic and very limited. -- RickArticle: 158391
On Friday, October 9, 2015 at 4:25:25 PM UTC-4, zak wrote: > Hi All, >=20 > In Altera devices (at least) it is recommended that reset be applied to > the async port of flips. It is also recommended that such reset should be > pre-synchronised before wiring it to these async ports. This saves > resource and helps recovery/removal timing.=20 >=20 > What exactly is recovery/removal. I know it is defined in terms of reset > release and that reset should not be de-asserted close to clock edge. Fai= r > enough but is this independent of D input? I mean if D input is stable (o= r > passes setup/hold) does it matter still that reset release near clock edg= e > will be problem on its own. From timieQuest it looks certainly that it > does matter but why? How is reset actually applied inside the flip? >=20 > Any help appreciated. >=20 > Zak > =20 > --------------------------------------- > Posted through http://www.FPGARelated.com One of fundamental aspects of implementing an asynchronous reset, which is = often overlooked, is that the reset must be DEASSERTED with proper timing m= argin with respect to the clock. This is why Altera, and many other vendor= s recommend synching the reset to the relevant clock domain. Recovery is d= efined as the setup time of the deassertion of the reset with respect to th= e clock. Removal is defined as the hold time of the deassertion of the res= et with respect to the clock. This is defined in the Altera documenation -= - I think it's in the Quartus handbook. Timequest does an excellent job = analyzing these paths if proper timing constraints are defined. Robert - lead VHDL/Verilog trainer www.digitaldesignconcepts.orgArticle: 158392
>One of fundamental aspects of implementing an asynchronous reset, which is >often overlooked, is that the reset must be DEASSERTED with proper timing >margin with respect to the clock. This is why Altera, and many other >vendors recommend synching the reset to the relevant clock domain. Recovery is >defined as the setup time of the deassertion of the reset with respect to >the clock. Removal is defined as the hold time of the deassertion of the >reset with respect to the clock. This is defined in the Altera documenation >-- I think it's in the Quartus handbook. Timequest does an excellent job >analyzing these paths if proper timing constraints are defined. > >Robert - lead VHDL/Verilog trainer >www.digitaldesignconcepts.org Thanks Robert, My original question was not about "standard" definitions of recovery/removal but rather the relation of reset deassertion to D input. Normally with setup/hold if D is not changing then timing violation does not apply. Does this apply to recovery/removal as well with respect to D input? I think Mark Curry answered my question. I will be grateful if you can share your views with this regard. Zak --------------------------------------- Posted through http://www.FPGARelated.comArticle: 158393
> >Normally with setup/hold if D is not changing then timing violation >does not apply. >Does this apply to recovery/removal as well with respect to D input? > If your D input is 1 then the timing between reset deassert and clock will determine whether the flop stays 0 or flips to 1. If your D input is 0 then it shouldn't matter because you are choosing between staying at 0 or loading a 0. Its the same result either way. The problem is that this depends on how the flop is implemented. If you build a flop using multiplexers and don't use glitchless muxes then it would be possible to see a 1 in this situation. Your silicon vendors data sheet should spell this out. If it is missing or ambiguous then be afraid, be very afraid. John Eaton --------------------------------------- Posted through http://www.FPGARelated.comArticle: 158394
On Thursday, October 29, 2015 at 11:04:19 AM UTC-4, jt_eaton wrote: > > > If your D input is 1 then the timing between reset deassert and clock will > determine whether the flop stays 0 or flips to 1. > > If your D input is 0 then it shouldn't matter because you are choosing > between staying at 0 or loading a 0. Its the same result either way. > If you violate timing you should not necessarily expect things to work properly so saying "...choosing between staying at 0 or loading a 0. Its the same result either way" on your second example is rolling the dice and hoping you won't get unlucky. Kevin JenningsArticle: 158395
>On Thursday, October 29, 2015 at 11:04:19 AM UTC-4, jt_eaton wrote: >> >> >> If your D input is 1 then the timing between reset deassert and clock >will >> determine whether the flop stays 0 or flips to 1. >> >> If your D input is 0 then it shouldn't matter because you are choosing >> between staying at 0 or loading a 0. Its the same result either way. >> > >If you violate timing you should not necessarily expect things to work >properly so saying "...choosing between staying at 0 or loading a 0. Its the >same result either way" on your second example is rolling the dice and >hoping you won't get unlucky. > >Kevin Jennings Well in that case how do we explain that the well documented reset sync design works. I mean that design that connects reset to async port of two stages synchroniser but connects D input of first register to '1'. If it is matter of dice that design would not be reliable as claimed. (also known as filtered reset design) Zak --------------------------------------- Posted through http://www.FPGARelated.comArticle: 158396
On Thursday, October 29, 2015 at 1:38:50 PM UTC-4, zak wrote: > >On Thursday, October 29, 2015 at 11:04:19 AM UTC-4, jt_eaton wrote: > >> > >> > >> If your D input is 1 then the timing between reset deassert and clock > >will > >> determine whether the flop stays 0 or flips to 1. > >> > >> If your D input is 0 then it shouldn't matter because you are choosing > >> between staying at 0 or loading a 0. Its the same result either way. > >> > > > >If you violate timing you should not necessarily expect things to work > >properly so saying "...choosing between staying at 0 or loading a 0. Its > the > >same result either way" on your second example is rolling the dice and > >hoping you won't get unlucky. > > > >Kevin Jennings > > Well in that case how do we explain that the well documented reset sync > design works. > I mean that design that connects reset to async port of two stages > synchroniser but connects D input of first register to '1'. If it is > matter of dice that design would not be reliable as claimed. (also known > as filtered reset design) > Several reasons: - If it really was so 'reliable' then you would only need one stage synchronizer, not two. But you do need two or more in order to be reliable because you will likely be violating timing on each flip flop in that reset synchronizer. - The resets you are talking about typically happen once per power up, not millions of times per second so the chances of you seeing it fail are slim - If you get an *extra* errant reset clock cycle for some reason you wouldn't know it because the system wouldn't reset. It's only if no reset gets generated that you *might* notice that things are not as they should be. - Most flip flops in a design do not need to be reset with a global reset at all. Those that don't have that need will be unaffected by whether or not there actually is a reset to that flip flop. Kevin JenningsArticle: 158397
> >Several reasons: >- If it really was so 'reliable' then you would only need one stage >synchronizer, not two. But you do need two or more in order to be reliable >because you will likely be violating timing on each flip flop in that reset >synchronizer. >Kevin Jennings I think you are misunderstanding the filtered reset design. It connects reset to async port of BOTH flops. So it is not worried about second flop i.e. no problem will occur there if reset is released near its clock edge and there is no third flop to put it right. Moreover Altera says this design metsatbility proof (I assume 100%) Zak --------------------------------------- Posted through http://www.FPGARelated.comArticle: 158398
On 10/29/2015 2:21 PM, zak wrote: >> >> Several reasons: >> - If it really was so 'reliable' then you would only need one stage >> synchronizer, not two. But you do need two or more in order to be > reliable >> because you will likely be violating timing on each flip flop in that > reset >> synchronizer. >> Kevin Jennings > > I think you are misunderstanding the filtered reset design. It connects > reset to async port of BOTH flops. So it is not worried about second flop > i.e. no problem will occur there if reset is released near its clock edge > and there is no third flop to put it right. > > Moreover Altera says this design metsatbility proof (I assume 100%) It has been demonstrated time and time again that there is no such thing as "metastability proof" in FFs. This also can occur in mechanical devices and I just realized that the penultimate mechanical time piece is subject to this problem. The Shortt double pendulum clock has a mechanism that speeds up the slave pendulum when needed based on the relative timing of the two pendulums. The mechanism that detects this is subject to metastability or a similar effect. When timed just "wrong", on the cusp of decision between fast and slow the mechanism misapplies the speed up mechanism giving a chaotic jolt to the slave pendulum (potentially the opposite of the intended direction). I expect this perturbation has little consequence, but it is interesting that it happens. The kicker on the master pendulum uses a gravity lever to give it a push every 30 swings. This is timed by the slave pendulum, so there will still be small perturbations in the strength of the push, but nothing like metastability that I can see. -- RickArticle: 158399
On Thursday, October 29, 2015 at 2:21:45 PM UTC-4, zak wrote: >=20 > I think you are misunderstanding the filtered reset design.=20 Or perhaps you're misunderstanding it. I'm assuming that you're referring = to 'Synchronized Asynchronous Reset' in chapter 12 of the Quartus handbook = (specifically, Figure 12-20) [1]...but who knows >=20 > Moreover Altera says this design metsatbility proof (I assume 100%) >=20 They made no such claim in this section. Altera states no reason for havin= g the second flip flop, but I would claim that it is there specifically for= metastability protection. As with any metastability protection, that seco= nd flip flop will not be a 100% guarantee, but it will be close enough to f= or practical purposes. You can assume whatever you want based on your incorrect recall of the circ= uit. That would be rolling the dice again. Kevin Jennings [1] https://www.altera.co.jp/ja_JP/pdfs/literature/hb/qts/qts_qii51006.pdf = page 12-32
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