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
On 11/13/2014 12:00 AM, glen herrmannsfeldt wrote: > rickman <gnuarm@gmail.com> wrote: > > (snip, someone wrote) > >>> As far as the OP is concerned, my only point was that the definition of >>> "work" is a legal one, and that - in general - attempts to circumvent >>> the GPL typically imply that the GPL does apply to the whole you're >>> trying to split up. This is hard enough to work through for software, >>> adding a hardware element to it makes it much harder. > >> Ok, this is where we started I believe. You have stated that it is >> "hard" to apply GPL to hardware. But I don't follow your reasoning in >> that regard. I don't see how it is any different from software. The >> fact that it costs more to replicate hardware than it does to replicate >> software doesn't seem relevant to me. > > Well, one reason relates to what copyright protects. It protects > the expression of the idea. In both cases, one can make a new expression > and avoid the copyright. In the case of a large software project, that > isn't likely. It would take a very long time to generate a different > expression of linux to get around its copyright. > > But in the case of hardware, reasonably often that isn't true. > Consider a PC board as an example hardware. I can redo the layout, > with exactly the same components wired up the same way, but with > completely different placement. IANAL, but I suspect that would get > around any copyright. Seems to me that if you take the netlist and > run it through a different PC board router, that would probably > be enough. You have to start with a schematic which is copyrighted. So this would need to be redone. The PCB layout would need to be redone from scratch. If you lift any portion of the PCB layout verbatim that is the same as plagiarizing a line or paragraph from a book. Yes, unless a design feature is patented, you can reuse the design concept. But that is not unique to hardware. I can rewrite software and I am no longer in violation of copyright. I don't see a significant difference. > That makes me wonder how hard it would be to write a program that > would generate a new expression of a software idea. Change it in > enough ways to avoid copyright, but such that the function was > guaranteed (as well as software can) to be the same. That is, > no human in the loop to make human errors. I don't know how copyright protects software. I mean I don't know just what constitutes violations and what does not. That is an issue for the courts to decide. > Not quite the same, but the usual way to get around drug patents > is to modify the molecule in some way. Add a methyl group onto > one ond, or hydroxyl on the other. Away from the active site, but > that is usually enough to get around a patent. With drugs changing one portion of the molecule *will* change the way it works 999 times out of 1000. That is why the various drugs for a single purpose all are qualified separately and have different side effects, etc. >> I don't see any reason why "applying a copyright license to physical >> hardware is both legally and philosophically difficult." It is done all >> the time. All of my products are copyrighted hardware. A recipient of >> GPLed hardware has the same rights as a recipient of a GPLed binary with >> the same level of effort required to enforce the GPL on those products. > > Have you tried suing anyone for illegally copying it? That is not an unusual occurrence. Here is even an example of *real* hardware being copied. Interesting that they are being sued for trademark infringement. I'm surprised that they can trademark a chair. Maybe that is over the name, "Navy" chair vs. "Naval" chair. http://www.woodworkingnetwork.com/wood-market-trends/woodworking-industry-news/production-woodworking-news/Restoration-Hardware-Sued-for-Chair-Design-Copies-174032731.html#sthash.2GAPnw9Y.dpbs -- RickArticle: 157276
Hi all, I always hear from FPGA designers that latches are "dangerous" and that it'= s very important avoiding them. I wonder what are the technical risks resul= ting by using latches. As far as I understand, the main problem is that FPG= As don't have built in hard latches so the synthesizer has to implement it = from logic blocks and then the race condition in the resulting logic is har= d/impossible to be analyzed. Is this main disadvantage latches? are there any other issues regarding lat= ches which shall be considered? Thanks, RonArticle: 157277
On 11/17/2014 4:17 AM, ronhk25 wrote: > Hi all, > > I always hear from FPGA designers that latches are "dangerous" and that it's very important avoiding them. I wonder what are the technical risks resulting by using latches. As far as I understand, the main problem is that FPGAs don't have built in hard latches so the synthesizer has to implement it from logic blocks and then the race condition in the resulting logic is hard/impossible to be analyzed. > Is this main disadvantage latches? are there any other issues regarding latches which shall be considered? It is not that latches are inherently bad. The problem is that they can be inferred unintentionally. The only time I remember using a latch in a design was way back when the 8085 CPU was around. I recall that they multiplexed the address with the data or with itself (upper/lower) and to get the best address setup time a latch was used, 74LS373 rather than the 74LS374 register. The address would flow through ahead of the edge of the clock that would hold it giving more address setup time. I believe that most programmable logic will implement latches ok. I'm not sure what race condition you are referring to. The only problem I can see is that if you use them in the wrong place they will let signals flow through successive latches rather than holding like registers will do. Oh yes, the static timing analysis program is incapable of calculating any timing analysis on them, so that is a real problem. I have never needed a latch in any HDL design I have worked on. Do you see a use for latches in your design? -- RickArticle: 157278
Hi Ron, ronhk25 <ronhk25@gmail.com> wrote: > I always hear from FPGA designers that latches are "dangerous" and > that it's very important avoiding them. What is 'dangerous' is not the latch in itself, rather the implicit instantiation of a latch because of an incomplete assignment. This is usually a sign something has been 'forgotten' by the designer, hence the danger. > I wonder what are the technical risks resulting by using latches. AFAIK, timing analysis may have problems because it performs setup/hold times verification based on clock propagation. If your enable signal is slower than the data in your latch you'll have issues that are hard to spot during timing analysis. > As far as I understand, > the main problem is that FPGAs don't have built in hard latches [...] Not true, there are devices with built in latches (ex. ProAsic from Microsemi) that are readily available even for automatic triplification to enhance radiation tolerance. I've never found the need to use a latch. HTH, AlArticle: 157279
You've got it almost correct. The only mistake is that it's not that they = are 'hard/impossible to be analyzed' though, it's because the race conditio= ns will cause the latch to fail if constructed out of logic blocks rather t= han a hard latch. A flip flop would fail in the same way if constructed ou= t of logic blocks as well. Kevin JenningsArticle: 157280
=D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A =D7=99=D7=95=D7=9D =D7=A9=D7=A0=D7=99,= 17 =D7=91=D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8 2014 11:17:04 UTC+2, =D7=9E= =D7=90=D7=AA ronhk25: > Hi all, >=20 > I always hear from FPGA designers that latches are "dangerous" and that i= t's very important avoiding them. I wonder what are the technical risks res= ulting by using latches. As far as I understand, the main problem is that F= PGAs don't have built in hard latches so the synthesizer has to implement i= t from logic blocks and then the race condition in the resulting logic is h= ard/impossible to be analyzed. > Is this main disadvantage latches? are there any other issues regarding l= atches which shall be considered? >=20 > Thanks, >=20 > Ron RIK and HTH thanks for your reply, RIK, regarding your question- in some cases while using combinatorical logi= c based state machines, i would like that some signals will keep their curr= ent values as a default (unless some defined conditions are met). I think t= hat this will result with latch since we get an asynchronous process (async= hronous decoders for the next state and for the output registers) with a si= gnal that its default value is its current value (i'm not that experinced w= ith asynchronous design so please correct me if i'm wrong...).=20 I agree that latches are not sound that usefull but sometimes i find myself= choosing not to use asynchronous processes in order to avoid from inferred= latches.Article: 157281
> RIK, regarding your question- in some cases while using combinatorical lo= gic based state machines, i would like that some signals will keep their cu= rrent values as a default (unless some defined conditions are met). This will result in a design that fails. If you're lucky it just never wor= ks, if you're not lucky you find that it doesn't work as you're manufacturi= ng is trying to build 1000 boards and find they are 'flaky'. Take what you= think to be a 'working' design' and spray some cold spray on the part and = watch it fail. If you're doing FPGA designs and you're using a part that does not have har= d latches, then you would be best off to abandon any use of combinatorial s= tate machines before you get burned. Kevin JenningsArticle: 157282
=D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A =D7=99=D7=95=D7=9D =D7=A9=D7=A0=D7=99,= 17 =D7=91=D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8 2014 11:17:04 UTC+2, =D7=9E= =D7=90=D7=AA ronhk25: > Hi all, >=20 > I always hear from FPGA designers that latches are "dangerous" and that i= t's very important avoiding them. I wonder what are the technical risks res= ulting by using latches. As far as I understand, the main problem is that F= PGAs don't have built in hard latches so the synthesizer has to implement i= t from logic blocks and then the race condition in the resulting logic is h= ard/impossible to be analyzed. > Is this main disadvantage latches? are there any other issues regarding l= atches which shall be considered? >=20 > Thanks, >=20 > Ron Rick and Al thanks for your reply,=20 RIK, regarding your question- in some cases while using combinatorial logic= based state machines, I would like that some signals will keep their curre= nt values as a default (unless some defined conditions are met). I think th= at this will result with latch since we get an asynchronous process (asynch= ronous decoders for the next state and for the output registers) with a sig= nal that its default value is its current value (I=E2=80=99m not that exper= ienced with asynchronous design so please correct me if I=E2=80=99m wrong..= .).=20 I agree that latches are not sound that useful but sometimes I find myself = choosing not to use asynchronous processes in order to avoid from inferred = latches.Article: 157283
ronhk25 wrote: > בתאריך יום שני, 17 בנובמבר 2014 11:17:04 UTC+2, מאת ronhk25: >> Hi all, >> >> I always hear from FPGA designers that latches are "dangerous" and that it's very important avoiding them. I wonder what are the technical risks resulting by using latches. As far as I understand, the main problem is that FPGAs don't have built in hard latches so the synthesizer has to implement it from logic blocks and then the race condition in the resulting logic is hard/impossible to be analyzed. >> Is this main disadvantage latches? are there any other issues regarding latches which shall be considered? >> >> Thanks, >> >> Ron > > RIK and HTH thanks for your reply, > > RIK, regarding your question- in some cases while using combinatorical logic based state machines, i would like that some signals will keep their current values as a default (unless some defined conditions are met). I think that this will result with latch since we get an asynchronous process (asynchronous decoders for the next state and for the output registers) with a signal that its default value is its current value (i'm not that experinced with asynchronous design so please correct me if i'm wrong...). > I agree that latches are not sound that usefull but sometimes i find myself choosing not to use asynchronous processes in order to avoid from inferred latches. There is a difference between an "asynchronous state machine" and "asynchronous" process included within a 2-proces (synchronous) state machine. The latter is often used, although generally not preferred by serious FPGA designers. If your decode logic is just for the "next" state, and the current state comes from a clocked register (edge-triggered flip-flop), then the correct way to retain the current state is to assign the output of the flop to the next state, rather than assigning next state to itself, which infers a latch. -- GaborArticle: 157284
Hi Ron, ronhk25 <ronhk25@gmail.com> wrote: [] > RIK, regarding your question- in some cases while using combinatorial > logic based state machines, I would like that some signals will keep > their current values as a default (unless some defined conditions are > met). Why do you want to implement combinatorial logic based state machines in the first place? What is the use case where there's a need for such an FSM w.r.t. clocked FSM? > I think that this will result with latch since we get an > asynchronous process (asynchronous decoders for the next state and for > the output registers) with a signal that its default value is its > current value (I’m not that experienced with asynchronous design so > please correct me if I’m wrong...). A signal whose 'default value is its current value' is hard for me to picture. Default is tipically that value the system is at rest when coming up, how can this value depend on the current value? > I agree that latches are not sound that useful but sometimes I find > myself choosing not to use asynchronous processes in order to avoid > from inferred latches. Think about the behavior you want to attain in the first place and only then reason in terms of asynchronous and/or synchronous. Remember always that timing analysis is critical for the *correct* functioning of your logic. If your design fails to meet design constraints it will likely fail the 'cold spray' test KJ mentioned...sooner or later! AlArticle: 157285
Hi,
>> I would like that some signals will keep their current values as a
default
Couldn't I always map it to a conventional (Mealy) machine with purely
registered state and purely combinational logic.
For example, take this little state machine with cmd input
- 0: hold value
- 1: increment
- 2: decrement
- 3: apply the last operation ("keep current value")
The default / last command has simply become part of the registered state.
input wire [1:0] cmd;
reg [31:0] count = 0;
reg [1:0] lastCmd = 0;
always @(posedge clk) begin
if (cmd != 3) begin
lastCmd <= cmd;
case (cmd)
0: begin end
1: count <= count+1;
2: count <= count-1;
/* 3: is impossible */
endcase
end else begin
case (lastCmd)
0: begin end
1: count <= count+1;
2: count <= count-1;
/* 3: is impossible */
endcase
end
end
---------------------------------------
Posted through http://www.FPGARelated.com
Article: 157286rickman wrote: > On 11/17/2014 4:17 AM, ronhk25 wrote: >> Hi all, >> >> I always hear from FPGA designers that latches are "dangerous" and >> that it's very important avoiding them. I wonder what are the >> technical risks resulting by using latches. As far as I understand, >> the main problem is that FPGAs don't have built in hard latches so the >> synthesizer has to implement it from logic blocks and then the race >> condition in the resulting logic is hard/impossible to be analyzed. >> Is this main disadvantage latches? are there any other issues >> regarding latches which shall be considered? > > It is not that latches are inherently bad. The problem is that they can > be inferred unintentionally. The only time I remember using a latch in > a design was way back when the 8085 CPU was around. I recall that they > multiplexed the address with the data or with itself (upper/lower) and > to get the best address setup time a latch was used, 74LS373 rather than > the 74LS374 register. The address would flow through ahead of the edge > of the clock that would hold it giving more address setup time. > > I believe that most programmable logic will implement latches ok. I'm > not sure what race condition you are referring to. The only problem I > can see is that if you use them in the wrong place they will let signals > flow through successive latches rather than holding like registers will > do. Oh yes, the static timing analysis program is incapable of > calculating any timing analysis on them, so that is a real problem. > > I have never needed a latch in any HDL design I have worked on. Do you > see a use for latches in your design? > When you present registers to be consumed or manipulated by a microprocessor ( say, memory mapped ) , are those what you are calling registers, or are they latches? Or is it "could go either way"? It's been a while but I remember them being a register with some different attributes form, a purely internal register. -- Les CargillArticle: 157287
Les Cargill <lcargill99@comcast.com> wrote: > rickman wrote: (snip regarding latches in modern logic) >> It is not that latches are inherently bad. The problem is that they can >> be inferred unintentionally. The only time I remember using a latch in >> a design was way back when the 8085 CPU was around. I recall that they >> multiplexed the address with the data or with itself (upper/lower) and >> to get the best address setup time a latch was used, 74LS373 rather than >> the 74LS374 register. The address would flow through ahead of the edge >> of the clock that would hold it giving more address setup time. As well as I remember, the 373 was always used for address lines, and the 374 usually for data lines. >> I believe that most programmable logic will implement latches ok. I'm >> not sure what race condition you are referring to. The only problem I >> can see is that if you use them in the wrong place they will let signals >> flow through successive latches rather than holding like registers will >> do. Oh yes, the static timing analysis program is incapable of >> calculating any timing analysis on them, so that is a real problem. Well, in the FPGA case you usually have edge-triggered FFs for free. As well as I know it, in the days before TTL (or probably ICs in general) it was not usual to use edge-triggered (master-slave) FFs. Processors often had two (or more) phase clocks to keep data from going where it wasn't supposed to go. It takes a lot more transistors to make an edge-triggered FF. See https://en.wikipedia.org/wiki/Flip-flop_%28electronics%29 for more. In the early days, the term was usually latch, I believe that flip-flop didn't come until somewhat later, maybe not until IC days. (Bistable multivibrator was used for some years, too. Monostable multivibrator is now usually known as a one-shot, and astable mutlivibrator is an oscillator.) >> I have never needed a latch in any HDL design I have worked on. >> Do you see a use for latches in your design? I am working on some designs based on old logic. Latches were not uncommon in the TTL days. The favorite display logic, such as for a frequency counter, was the 7490 ripple counter, 7475 latch, and then 7447 BCD to 7-segment decoder. (Earlier, the 7441 and Nixie (tm) tube.) Reset the counters, let them count with the latch open, (users can see the numbers change) then close the latch. Similar the way split times are done with a stop watch. The counters can keep running, but you latch the data once in a while. (For faster counts, there could be some race conditions.) > When you present registers to be consumed or manipulated by a > microprocessor ( say, memory mapped ) , are those what you are > calling registers, or are they latches? > Or is it "could go either way"? "Transparent latch" and "edge-triggered master-slave flip flop" are pretty unambiguous. Everything else, you can't be sure. > It's been a while but I remember them being a register with some > different attributes form, a purely internal register. -- glenArticle: 157288
KJ <kkjennings@sbcglobal.net> wrote: > You've got it almost correct. The only mistake is that it's not > that they are 'hard/impossible to be analyzed' though, it's > because the race conditions will cause the latch to fail if > constructed out of logic blocks rather than a hard latch. That isn't always true, but you do have to do it right. In the pre-TTL days it was usual to have a two-phase clock. It is then easy to avoid race conditions with appropriate non-overlap of the phases. Many early microprocessors used a two-phase clock, and some even four phase. (Remembering from years ago, the TMS9900 uses four.) But yes, with one clock signal you are pretty much stuck. > A flip flop would fail in the same way if constructed out of > logic blocks as well. To make an edge-triggered FF, as I understand the design, you need logic with different threshold voltages. You don't get that with FPGA logic. -- glenArticle: 157289
On Monday, November 17, 2014 2:43:25 PM UTC-5, glen herrmannsfeldt wrote: > KJ wrote: >=20 > > You've got it almost correct. The only mistake is that it's not=20 > > that they are 'hard/impossible to be analyzed' though, it's=20 > > because the race conditions will cause the latch to fail if=20 > > constructed out of logic blocks rather than a hard latch. =20 >=20 > That isn't always true, but you do have to do it right. In the pre-TTL > days it was usual to have a two-phase clock. It is then easy to > avoid race conditions with appropriate non-overlap of the phases. >=20 Creating a latch has nothing to do with two-phase clocks. In order to reli= ably create a latch out of logic you need to specify redundant logic terms = and then insure that the logic gets implemented exactly that way, like this= ... Q <=3D (D and EN) or (Q and not(EN)) or (D and Q); The 'D and Q' term is redundant and any synthesizer will remove it. Howeve= r, when that term gets removed the latch will no longer be reliable because= of the race when the falling edge of EN occurs. As long as one has no abs= olute control over propagation delays (which you will not as a user of an F= PGA or CPLD), you will not be able to reliably create a latch. So you have to specify the logic shown above and then add synthesis attribu= tes to prevent removal of logic terms for 'Q'. End of story. Kevin JenningsArticle: 157290
On 11/17/2014 1:30 PM, Les Cargill wrote: > rickman wrote: >> On 11/17/2014 4:17 AM, ronhk25 wrote: >>> Hi all, >>> >>> I always hear from FPGA designers that latches are "dangerous" and >>> that it's very important avoiding them. I wonder what are the >>> technical risks resulting by using latches. As far as I understand, >>> the main problem is that FPGAs don't have built in hard latches so the >>> synthesizer has to implement it from logic blocks and then the race >>> condition in the resulting logic is hard/impossible to be analyzed. >>> Is this main disadvantage latches? are there any other issues >>> regarding latches which shall be considered? >> >> It is not that latches are inherently bad. The problem is that they can >> be inferred unintentionally. The only time I remember using a latch in >> a design was way back when the 8085 CPU was around. I recall that they >> multiplexed the address with the data or with itself (upper/lower) and >> to get the best address setup time a latch was used, 74LS373 rather than >> the 74LS374 register. The address would flow through ahead of the edge >> of the clock that would hold it giving more address setup time. >> >> I believe that most programmable logic will implement latches ok. I'm >> not sure what race condition you are referring to. The only problem I >> can see is that if you use them in the wrong place they will let signals >> flow through successive latches rather than holding like registers will >> do. Oh yes, the static timing analysis program is incapable of >> calculating any timing analysis on them, so that is a real problem. >> >> I have never needed a latch in any HDL design I have worked on. Do you >> see a use for latches in your design? >> > > When you present registers to be consumed or manipulated by a > microprocessor ( say, memory mapped ) , are those what you are calling > registers, or are they latches? > > Or is it "could go either way"? > > It's been a while but I remember them being a register with some > different attributes form, a purely internal register. I can't say I understand your question on several points. I don't know what it means to "consume" a register. The definition of a register is a storage element that is edge sensitive while a latch is level sensitive. Assert the enable of a latch and it passes the data input to the output. When the enable is removed it remembers the last value on the output. A register output is only affected by sampling the data input on the clock edge (rising or falling but not both) and presenting it to the output. In light of that can you rephrase your question? -- RickArticle: 157291
On 11/17/2014 3:21 PM, KJ wrote: > On Monday, November 17, 2014 2:43:25 PM UTC-5, glen herrmannsfeldt wrote: >> KJ wrote: >> >>> You've got it almost correct. The only mistake is that it's not >>> that they are 'hard/impossible to be analyzed' though, it's >>> because the race conditions will cause the latch to fail if >>> constructed out of logic blocks rather than a hard latch. >> >> That isn't always true, but you do have to do it right. In the pre-TTL >> days it was usual to have a two-phase clock. It is then easy to >> avoid race conditions with appropriate non-overlap of the phases. >> > > Creating a latch has nothing to do with two-phase clocks. In order to reliably create a latch out of logic you need to specify redundant logic terms and then insure that the logic gets implemented exactly that way, like this... > > Q <= (D and EN) or (Q and not(EN)) or (D and Q); > > The 'D and Q' term is redundant and any synthesizer will remove it. However, when that term gets removed the latch will no longer be reliable because of the race when the falling edge of EN occurs. As long as one has no absolute control over propagation delays (which you will not as a user of an FPGA or CPLD), you will not be able to reliably create a latch. > > So you have to specify the logic shown above and then add synthesis attributes to prevent removal of logic terms for 'Q'. End of story. You are thinking old school where the logic is made up of gates. In an FPGA the programmable logic is made from LUTs which are memory elements programmed at configuration time and so are fixed 1s and 0s during operation and multiplexors made from transmission gates. Some esteemed Xilinx representatives pointed out that the transmission gate multiplexors can be constructed to assure that the transition of a single input will *not* cause a glitch so that Q <= (D and EN) or (Q and not(EN)) or (D and Q); and Q <= (D and EN) or (Q and not(EN)); Give the same results on the transition of EN. I believe that since transmission gates will either both be on during the transition (connecting the output to the same value inputs in this case) or will both be off during the transition (with the previous state held by the capacitance on the output node) no glitch will be presented to the output. Latches can be synthesized correctly in FPGAs using the logic fabric. -- RickArticle: 157292
On 11/17/2014 6:42 AM, ronhk25 wrote: > בתאריך יום שני, 17 בנובמבר 2014 11:17:04 UTC+2, מאת ronhk25: >> Hi all, >> >> I always hear from FPGA designers that latches are "dangerous" and that it's very important avoiding them. I wonder what are the technical risks resulting by using latches. As far as I understand, the main problem is that FPGAs don't have built in hard latches so the synthesizer has to implement it from logic blocks and then the race condition in the resulting logic is hard/impossible to be analyzed. >> Is this main disadvantage latches? are there any other issues regarding latches which shall be considered? >> >> Thanks, >> >> Ron > > RIK and HTH thanks for your reply, > > RIK, regarding your question- in some cases while using combinatorical logic based state machines, i would like that some signals will keep their current values as a default (unless some defined conditions are met). I think that this will result with latch since we get an asynchronous process (asynchronous decoders for the next state and for the output registers) with a signal that its default value is its current value (i'm not that experinced with asynchronous design so please correct me if i'm wrong...). > I agree that latches are not sound that usefull but sometimes i find myself choosing not to use asynchronous processes in order to avoid from inferred latches. I can't say I follow your point. A register keeps its value as a default if there is no change specified. If you are talking about an asynchronous state machine, then there is no clock at all. That is a different animal altogether and not so easy to do in an FPGA. Yes, this will result in the formation of what would be considered a "latch", but without a clock! The inputs to the async FSM each trigger transitions and as Kevin was discussing, require coverage terms for each and every transition. I remember learning this in college and *never* using it in practice. One colleague used an async FSM chip in a design many years ago. I've never seen an async FSM since unless you count an RS FF as an async FSM, lol. -- RickArticle: 157293
On Monday, November 17, 2014 3:40:23 PM UTC-5, rickman wrote: > On 11/17/2014 3:21 PM, KJ wrote: > > So you have to specify the logic shown above and then add synthesis=20 > > attributes to prevent removal of logic terms for 'Q'. End of story. >=20 > You are thinking old school where the logic is made up of gates. No I'm not. > Some esteemed=20 > Xilinx representatives pointed out that the transmission gate=20 > multiplexors can be constructed to assure that the transition of a=20 > single input will *not* cause a glitch so that >=20 > Q <=3D (D and EN) or (Q and not(EN)) or (D and Q); >=20 > and >=20 > Q <=3D (D and EN) or (Q and not(EN)); >=20 > Give the same results on the transition of EN. >=20 The 'esteemed Xilinx representatives' probably did not say all of that. Th= ey might have stopped somewhere at '..to assure that the transition of a=20 single input will *not* cause a glitch'. But also note that you're relying= on the word of a rep here to somehow guarantee that the final synthesized = logic will be created in such a way that there will only be one switching i= nput to that LUT. Remember, this is a stripped down example. The actual c= loud of logic that generates 'D' and 'EN' are not necessarily signal inputs= to the LUT. There might not be a discrete 'D' or 'EN' signal input...unle= ss you go through the trouble of creating and correctly applying synthesis = attributes (which I'm not recommending...I recommend to avoid all forms of = transparent latch type of stuff). Even if 'D' and 'EN' are discrete, I wou= ldn't rely on somebody's word that the logic hazard can be safely avoided i= nside a LUT. Draw the Karnaugh map and look for the logic hazard. That is what the last= term covers. It doesn't matter whether the implementation is in gates, CP= LD product terms or FPGA lookup tables. If you want a reliable latch you'l= l cover the hazard with the cover term. >=20 > Latches can be synthesized correctly in FPGAs using the logic fabric. >=20 Do you have a reference to support that specific statement? I've only seen them fail, but granted I was mostly debugging someone's inte= rmittent problem to start with. But I've also taken 'working' designs with= latches and made them fail with cold spray that did not fail when the desi= gn was changed to use flip flops. Kevin JenningsArticle: 157294
On 11/17/2014 4:01 PM, KJ wrote: > On Monday, November 17, 2014 3:40:23 PM UTC-5, rickman wrote: >> On 11/17/2014 3:21 PM, KJ wrote: >>> So you have to specify the logic shown above and then add synthesis >>> attributes to prevent removal of logic terms for 'Q'. End of story. > >> >> You are thinking old school where the logic is made up of gates. > > No I'm not. > >> Some esteemed >> Xilinx representatives pointed out that the transmission gate >> multiplexors can be constructed to assure that the transition of a >> single input will *not* cause a glitch so that >> >> Q <= (D and EN) or (Q and not(EN)) or (D and Q); >> >> and >> >> Q <= (D and EN) or (Q and not(EN)); >> >> Give the same results on the transition of EN. >> > > The 'esteemed Xilinx representatives' probably did not say all of that. Actually he did. If you dig around you can probably find the thread. I think it was the late Peter Alfke discussing exactly this issue of latches in the logic fabric. > They might have stopped somewhere at '..to assure that the transition of a > single input will *not* cause a glitch'. But also note that you're relying on the word of a rep here to somehow guarantee that the final synthesized logic will be created in such a way that there will only be one switching input to that LUT. Remember, this is a stripped down example. The actual cloud of logic that generates 'D' and 'EN' are not necessarily signal inputs to the LUT. There might not be a discrete 'D' or 'EN' signal input...unless you go through the trouble of creating and correctly applying synthesis attributes (which I'm not recommending...I recommend to avoid all forms of transparent latch type of stuff). Even if 'D' and 'EN' are discrete, I wouldn't rely on somebody's word that the logic hazard can be safely avoided inside a LUT. Yes, I can guarantee there will be only one switching input to the LUT, the CLOCK! Even for a latch there is a setup and hold time spec so the D input must be stationary during the time around the enable being deasserted. It doesn't matter how many other signals go into making that D input. They must *all* be stationary during the setup/hold time window. > Draw the Karnaugh map and look for the logic hazard. That is what the last term covers. It doesn't matter whether the implementation is in gates, CPLD product terms or FPGA lookup tables. If you want a reliable latch you'll cover the hazard with the cover term. Now you are in denial. I explained how the capacitance of the output node acts as a memory element during the switching time where there can be a short interval when *all* transmission gates are off so the node is not driven. That is how the cover term is provided, by a memory element. >> Latches can be synthesized correctly in FPGAs using the logic fabric. >> > Do you have a reference to support that specific statement? Me, I've just explained it to you. If you want more proof, find the posts by the Xilinx people. > I've only seen them fail, but granted I was mostly debugging someone's intermittent problem to start with. But I've also taken 'working' designs with latches and made them fail with cold spray that did not fail when the design was changed to use flip flops. What parts were these in? I would like to know more about this. The info I had was from Xilinx and only applied to Xilinx parts of course. Since I have never needed a latch I have not done any searching to see if this is more generally supported in FPGAs. -- RickArticle: 157295
rickman <gnuarm@gmail.com> wrote: > On 11/17/2014 3:21 PM, KJ wrote: (snip where I mentioned two-phase clocks) >> Creating a latch has nothing to do with two-phase clocks. >> In order to reliably create a latch out of logic you need >> to specify redundant logic terms and then insure that the >> logic gets implemented exactly that way, like this... >> Q <= (D and EN) or (Q and not(EN)) or (D and Q); >> The 'D and Q' term is redundant and any synthesizer will remove it. >> However, when that term gets removed the latch will no longer be >> reliable because of the race when the falling edge of EN occurs. >> As long as one has no absolute control over propagation delays >> (which you will not as a user of an FPGA or CPLD), you will not >> be able to reliably create a latch. >> So you have to specify the logic shown above and then add >> synthesis attributes to prevent removal of logic terms for 'Q'. >> End of story. > You are thinking old school where the logic is made up of gates. In an > FPGA the programmable logic is made from LUTs which are memory elements > programmed at configuration time and so are fixed 1s and 0s during > operation and multiplexors made from transmission gates. Some esteemed > Xilinx representatives pointed out that the transmission gate > multiplexors can be constructed to assure that the transition of a > single input will *not* cause a glitch so that Oh, that is what he was asking about? OK, yes. I didn't figure out that is what he meant. > Q <= (D and EN) or (Q and not(EN)) or (D and Q); > and > Q <= (D and EN) or (Q and not(EN)); > Give the same results on the transition of EN. > I believe that since transmission gates will either both be on during > the transition (connecting the output to the same value inputs in this > case) or will both be off during the transition (with the previous state > held by the capacitance on the output node) no glitch will be presented > to the output. The way I think about it is, that when one input changes, and the output doesn't change value, there won't be a glitch. That isn't obvious if you think about the usual way of making multiplexers. > Latches can be synthesized correctly in FPGAs using the logic fabric. I agree. But he did also point out that the current tools aren't so good at figuring out the timing. You want to know how fast you can run the clock, and still get the right output. If you design with the usual edge triggered FFs, it is all done almost automatically. A little more work in this case. -- glenArticle: 157296
KJ wrote: > You've got it almost correct. The only mistake is that it's not that they are 'hard/impossible to be analyzed' though, it's because the race conditions will cause the latch to fail if constructed out of logic blocks rather than a hard latch. A flip flop would fail in the same way if constructed out of logic blocks as well. > > Kevin Jennings Some points: Most Xilinx FPGA's have the ability to configure the fabric flops as a gated latch rather than an edge-triggered flop. These are quite robust latches and work as you might expect a gated latch to work. Xilinx's own XST synthesis is happy to infer them for you (with warnings, because as mentioned elsewhere, latch inference is often unintentional). Even these beautiful hard gated latches will have problems if your code generates the enable signal using a combinatorial decode of several synchronous signals. Furthermore, the gate input needs to come from the clock pin of the slice. Since the gate signal is rarely a system clock line, you often lose a lot of slice logic because it cannot get another clock routed to the same slice. Probably not a big issue if you use a latch here or there in an otherwise synchronous design, but it makes a mostly asynchronous design very large in terms of slice footprint. The same parts will fail miserably if you try to build asynchronous sequential logic using just the LUTs. One reason is that you cannot prevent the tools from removing coverage terms, short of directly instantiating the LUTs with your own INIT attributes (LUT contents). Xilinx *does* guarantee that a LUT with one input switching will not glitch going from a 1 to a 1 or a 0 to a 0. There are no guarantees when multiple inputs switch mostly because it is impossible to route such that they switch at exactly the same time. The timing analyzer also tends to be overly conservative when determining timing through a transparent latch. One of the points of the latch is that it can add to setup time at the next flop by passing through the input while the gate is "open." The tools however will look at the gate enable path as a worse case rather than the data, and in some cases falsely state that your timing will not work. This leads to a lot of hand analysis of the timing. In general, the Xilinx tools are very solid and give reliable results when your design is completely synchronous. -- GaborArticle: 157297
rickman wrote: > On 11/17/2014 1:30 PM, Les Cargill wrote: >> rickman wrote: >>> On 11/17/2014 4:17 AM, ronhk25 wrote: >>>> Hi all, >>>> >>>> I always hear from FPGA designers that latches are "dangerous" and >>>> that it's very important avoiding them. I wonder what are the >>>> technical risks resulting by using latches. As far as I understand, >>>> the main problem is that FPGAs don't have built in hard latches so the >>>> synthesizer has to implement it from logic blocks and then the race >>>> condition in the resulting logic is hard/impossible to be analyzed. >>>> Is this main disadvantage latches? are there any other issues >>>> regarding latches which shall be considered? >>> >>> It is not that latches are inherently bad. The problem is that they can >>> be inferred unintentionally. The only time I remember using a latch in >>> a design was way back when the 8085 CPU was around. I recall that they >>> multiplexed the address with the data or with itself (upper/lower) and >>> to get the best address setup time a latch was used, 74LS373 rather than >>> the 74LS374 register. The address would flow through ahead of the edge >>> of the clock that would hold it giving more address setup time. >>> >>> I believe that most programmable logic will implement latches ok. I'm >>> not sure what race condition you are referring to. The only problem I >>> can see is that if you use them in the wrong place they will let signals >>> flow through successive latches rather than holding like registers will >>> do. Oh yes, the static timing analysis program is incapable of >>> calculating any timing analysis on them, so that is a real problem. >>> >>> I have never needed a latch in any HDL design I have worked on. Do you >>> see a use for latches in your design? >>> >> >> When you present registers to be consumed or manipulated by a >> microprocessor ( say, memory mapped ) , are those what you are calling >> registers, or are they latches? >> >> Or is it "could go either way"? >> >> It's been a while but I remember them being a register with some >> different attributes form, a purely internal register. > > I can't say I understand your question on several points. I don't know > what it means to "consume" a register. > > The definition of a register is a storage element that is edge sensitive > while a latch is level sensitive. I think that actually answered my question - it could be either depending on how you wanted it to work. > Assert the enable of a latch and it > passes the data input to the output. When the enable is removed it > remembers the last value on the output. A register output is only > affected by sampling the data input on the clock edge (rising or falling > but not both) and presenting it to the output. > So basically, a register latches on a clock edge. > In light of that can you rephrase your question? > Suppose we have a memory mapped segment on a CPU that "goes to" a register bank in an FPGA. Are those bits latches/latched or not, or are they a mix? -- Les CargillArticle: 157298
GaborSzakacs <gabor@alacron.com> wrote: (snip on latch vs. register) > Some points: > Most Xilinx FPGA's have the ability to configure the fabric > flops as a gated latch rather than an edge-triggered flop. > These are quite robust latches and work as you might expect > a gated latch to work. Xilinx's own XST synthesis is happy > to infer them for you (with warnings, because as mentioned > elsewhere, latch inference is often unintentional). (snip) > The same parts will fail miserably if you try to build > asynchronous sequential logic using just the LUTs. One > reason is that you cannot prevent the tools from removing > coverage terms, short of directly instantiating the LUTs > with your own INIT attributes (LUT contents). > Xilinx *does* guarantee that a LUT with one input switching > will not glitch going from a 1 to a 1 or a 0 to a 0. There > are no guarantees when multiple inputs switch mostly because > it is impossible to route such that they switch at exactly > the same time. > The timing analyzer also tends to be overly conservative when > determining timing through a transparent latch. One of the points > of the latch is that it can add to setup time at the next flop > by passing through the input while the gate is "open." The > tools however will look at the gate enable path as a worse case > rather than the data, and in some cases falsely state that your > timing will not work. This leads to a lot of hand analysis of > the timing. In computer designs from the 1950's and 1960's, everything was latch, and they still worked. It takes a lot more transistors to make an edge-triggered master-slave FF, and transistors were expensive! One interesting latch design from the 1960's is the Earle latch: https://en.wikipedia.org/wiki/Flip-flop_%28electronics%29#Earle_latch As noted, in many cases you can combine two levels of logic with the logic of the latch. In a pipelined processor, that can make a big difference in how much logic you get at each stage, or at least did before the fast transistors that we have today. -- glenArticle: 157299
On 11/17/2014 7:21 PM, Les Cargill wrote: > rickman wrote: >> On 11/17/2014 1:30 PM, Les Cargill wrote: >>> rickman wrote: >>>> On 11/17/2014 4:17 AM, ronhk25 wrote: >>>>> Hi all, >>>>> >>>>> I always hear from FPGA designers that latches are "dangerous" and >>>>> that it's very important avoiding them. I wonder what are the >>>>> technical risks resulting by using latches. As far as I understand, >>>>> the main problem is that FPGAs don't have built in hard latches so the >>>>> synthesizer has to implement it from logic blocks and then the race >>>>> condition in the resulting logic is hard/impossible to be analyzed. >>>>> Is this main disadvantage latches? are there any other issues >>>>> regarding latches which shall be considered? >>>> >>>> It is not that latches are inherently bad. The problem is that they >>>> can >>>> be inferred unintentionally. The only time I remember using a latch in >>>> a design was way back when the 8085 CPU was around. I recall that they >>>> multiplexed the address with the data or with itself (upper/lower) and >>>> to get the best address setup time a latch was used, 74LS373 rather >>>> than >>>> the 74LS374 register. The address would flow through ahead of the edge >>>> of the clock that would hold it giving more address setup time. >>>> >>>> I believe that most programmable logic will implement latches ok. I'm >>>> not sure what race condition you are referring to. The only problem I >>>> can see is that if you use them in the wrong place they will let >>>> signals >>>> flow through successive latches rather than holding like registers will >>>> do. Oh yes, the static timing analysis program is incapable of >>>> calculating any timing analysis on them, so that is a real problem. >>>> >>>> I have never needed a latch in any HDL design I have worked on. Do you >>>> see a use for latches in your design? >>>> >>> >>> When you present registers to be consumed or manipulated by a >>> microprocessor ( say, memory mapped ) , are those what you are calling >>> registers, or are they latches? >>> >>> Or is it "could go either way"? >>> >>> It's been a while but I remember them being a register with some >>> different attributes form, a purely internal register. >> >> I can't say I understand your question on several points. I don't know >> what it means to "consume" a register. >> >> The definition of a register is a storage element that is edge sensitive >> while a latch is level sensitive. > > > I think that actually answered my question - it could be either > depending on how you wanted it to work. > >> Assert the enable of a latch and it >> passes the data input to the output. When the enable is removed it >> remembers the last value on the output. A register output is only >> affected by sampling the data input on the clock edge (rising or falling >> but not both) and presenting it to the output. >> > > So basically, a register latches on a clock edge. > >> In light of that can you rephrase your question? >> > > > Suppose we have a memory mapped segment on a CPU that "goes to" a > register bank in an FPGA. Are those bits latches/latched or not, > or are they a mix? I'm still not grasping the question. The issue of being memory mapped is not related to whether the memory is implemented as latches or registers. There are at least two issues here. One is how you code the "memory". If you code it as a latch it will be a latch. The other is how such logic is actually implemented in the FPGA. If you just code memory (all such memory and other storage elements in an FPGA are edge triggered and so really are registers technically) how do they actually implement the memory in the FPGA? I don't know for sure. I see mention of 6 transistor RAM being the standard elements in processors for static memory, I expect that is also what they use for FPGA memories (not the registers used in the logic fabric). Then they likely fake the interface to work like a register or actually put registers in the address/data path and synthesize the timing controls for the RAM array invisibly to the user. I remember when they stopped providing static RAM from the LUTs and made it edge sensitive. They had too many users who sucked at designing with async memory (which works like latches) and so just made it look like sync memory (which looks like registers). The info they provided basically said this was async memory with a faked out interface and they synthesized the write strobe for you. Lol, I hope that isn't too confusing. -- Rick
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