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/17/2014 8:16 PM, glen herrmannsfeldt wrote: > 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! No, not really. All they did was to make the clocking more complicated, unless they were using dynamic latches (capacitors) to store the digital value for a very short time resulting in a minimum clock rate. To use latches you have to have at least two non-overlapping clocks and two sets of latches. That is exactly what an edge triggered FF is, two latches with non-overlapping clocks allowing the input to be held by the first latch and then before the gate opens again the value is stored into a second latch. The output changes when the second latch gate opens but at that point the input is already isolated so it appears as if the input is "clocked" into the register on the edge. These early machines either used dynamic storage (which is *very* simple) or they were just splitting the register into two halves (each a latch) one on each clock phase (sometimes three or even four). > 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. Yep -- RickArticle: 157301
rickman <gnuarm@gmail.com> wrote: (snip, I wrote) >> 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! > No, not really. All they did was to make the clocking more complicated, > unless they were using dynamic latches (capacitors) to store the digital > value for a very short time resulting in a minimum clock rate. Many of the early microprocessers used dynamic logic. Also, some systems used dynamic shift registers for storage. Don Lancaster's TV typewriter (the display part of a video terminal) uses 512 bit MOS shift registers to store the screen data. > To use latches you have to have at least two non-overlapping clocks and > two sets of latches. That is exactly what an edge triggered FF is, two > latches with non-overlapping clocks allowing the input to be held by the > first latch and then before the gate opens again the value is stored > into a second latch. The output changes when the second latch gate > opens but at that point the input is already isolated so it appears as > if the input is "clocked" into the register on the edge. Yes, but you can do: (logic) (phase A latch) (logic) (phase B latch) ... I never did figure out what to do with four phases, though. > These early machines either used dynamic storage (which is *very* > simple) or they were just splitting the register into two halves (each a > latch) one on each clock phase (sometimes three or even four). >> 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. > Yep -- glenArticle: 157302
On 11/18/2014 12:31 AM, glen herrmannsfeldt wrote: > rickman <gnuarm@gmail.com> wrote: > > (snip, I wrote) >>> 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! > >> No, not really. All they did was to make the clocking more complicated, >> unless they were using dynamic latches (capacitors) to store the digital >> value for a very short time resulting in a minimum clock rate. > > Many of the early microprocessers used dynamic logic. > > Also, some systems used dynamic shift registers for storage. > > Don Lancaster's TV typewriter (the display part of a video terminal) > uses 512 bit MOS shift registers to store the screen data. > >> To use latches you have to have at least two non-overlapping clocks and >> two sets of latches. That is exactly what an edge triggered FF is, two >> latches with non-overlapping clocks allowing the input to be held by the >> first latch and then before the gate opens again the value is stored >> into a second latch. The output changes when the second latch gate >> opens but at that point the input is already isolated so it appears as >> if the input is "clocked" into the register on the edge. > > Yes, but you can do: > > (logic) (phase A latch) (logic) (phase B latch) ... Yes and the two latches is equivalent to a single register in terms of functionality and complexity. It doesn't save any timing. It just requires that you distribute two clock phases. I expect this was mostly used with dynamic storage since that is always latches and not registers. > I never did figure out what to do with four phases, though. I can't say, but I still have a TMS9900 SBC with a four phase clock. I was rummaging in the basement the other day and found a TMS9995 CPU board I had built too. I don't think I ever got that one doing anything useful. I see it is hooked up to an old LCD display that came out of UPS trucks way back when. I have enough old junk that I could start my own computer museum. But I already threw out my LSI-11, some 15 or more years ago. It was a heathkit with 8" floppy drives. I think that is why I ditched it. While an SBC is always relevant what am I going to do with RT-11 on floppy disks? -- RickArticle: 157303
rickman <gnuarm@gmail.com> wrote: (snip) > I have enough old junk that I could start my own computer museum. But I > already threw out my LSI-11, some 15 or more years ago. It was a > heathkit with 8" floppy drives. I think that is why I ditched it. > While an SBC is always relevant what am I going to do with RT-11 on > floppy disks? http://www.livingcomputermuseum.org/default.aspx -- glenArticle: 157304
glen herrmannsfeldt wrote: > 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. > > -- glen > The point of this thread isn't really that there's an inherent problem with latches. The issue is that FPGA's aren't designed to create asynchronous sequential logic. Folding a bunch of 2-input gates from your RTL into a LUT results in a huge change in the timing characteristics of the logic. Any structure that doesn't already exist in the slice or logic cell gets converted into LUTs. Trying to build an edge-triggered D flop from LUTs will fail just as miserably as an attempt to create latches that way. The older TI TTL catalogs had a schematic representation of a 7474 flip-flop that consists of 6 3-input NAND gates. Code that up in an FPGA and see what happens... -- GaborArticle: 157305
=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 Thank you all for your answers!=20 I would like to clarify- I didn't mean to combinatorial state machines, I m= eant to a "multi-process synchronous state machine" while the output signal= s and the next state are assigned in an asynchronic process and the current= state is assigned in a synchronous process, i understand that this kind of= state machine is defined as synchronous state machine. I'm not experienced= with that kind of state machines as in the past I have always used one clo= cked process in my state machines but in my new job I'm obliged to use the = HDL designer graphical tool which generates those "multi-process synchronou= s state machine". Now, as i wrote, the output signals are assigned in an as= ynchronous process and in some states i want that some of the outputs will = keep their last assigned value. In synchronous process this is not a problem since a flip flop is used but in asynchronous process an inferred latches might be created. Those unintended latches made me open this thread, what are your recommenda= tions to this issue?Article: 157306
GaborSzakacs <gabor@alacron.com> wrote: (snip, I wrote) >> 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! (snip) > The point of this thread isn't really that there's an inherent > problem with latches. The issue is that FPGA's aren't designed > to create asynchronous sequential logic. Folding a bunch of > 2-input gates from your RTL into a LUT results in a huge change > in the timing characteristics of the logic. Any structure that > doesn't already exist in the slice or logic cell gets converted > into LUTs. I am at least slightly interested (though I might never get around to) recreating old designs in FPGA logic. Hardware emulation is just a little bit different from software emulation. > Trying to build an edge-triggered D flop from LUTs > will fail just as miserably as an attempt to create latches that > way. The older TI TTL catalogs had a schematic representation > of a 7474 flip-flop that consists of 6 3-input NAND gates. Code > that up in an FPGA and see what happens... I believe it will also fail if you build it out of TTL gates. Some of the schematics in the TTL data book are written with transistors, others with gates. Even so, I don't believe that all that are written with gates can be implemented with actual separate TTL gates. And yes, not in an FPGA, either. -- glenArticle: 157307
glen herrmannsfeldt wrote: > GaborSzakacs <gabor@alacron.com> wrote: > > (snip, I wrote) > >>> 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! > > (snip) > >> The point of this thread isn't really that there's an inherent >> problem with latches. The issue is that FPGA's aren't designed >> to create asynchronous sequential logic. Folding a bunch of >> 2-input gates from your RTL into a LUT results in a huge change >> in the timing characteristics of the logic. Any structure that >> doesn't already exist in the slice or logic cell gets converted >> into LUTs. > > I am at least slightly interested (though I might never get > around to) recreating old designs in FPGA logic. Hardware > emulation is just a little bit different from software emulation. > >> Trying to build an edge-triggered D flop from LUTs >> will fail just as miserably as an attempt to create latches that >> way. The older TI TTL catalogs had a schematic representation >> of a 7474 flip-flop that consists of 6 3-input NAND gates. Code >> that up in an FPGA and see what happens... > > I believe it will also fail if you build it out of TTL gates. > No it won't. It will just be really slow compared to an actual 74xx74 chip of the same TTL family. Unlike the FPGA where the gates get lumped together into LUTs, the TTL 3-input NAND gates will be wired just like the diagram and keep the causality relationship between inputs and outputs. You can also make a working flip-flop using FPGA LUTs as individual 3-input NAND gates, but the tools will force you to instantiate the LUTs to prevent their being combined during optimization. > Some of the schematics in the TTL data book are written with > transistors, others with gates. Even so, I don't believe that all > that are written with gates can be implemented with actual > separate TTL gates. And yes, not in an FPGA, either. > > -- glenArticle: 157308
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 > > Thank you all for your answers! > I would like to clarify- I didn't mean to combinatorial state machines, I meant to a "multi-process synchronous state machine" while the output signals and the next state are assigned in an asynchronic process and the current state is assigned in a synchronous process, i understand that this kind of state machine is defined as synchronous state machine. I'm not experienced with that kind of state machines as in the past I have always used one clocked process in my state machines but in my new job I'm obliged to use the HDL designer graphical tool which generates those "multi-process synchronous state machine". Now, as i wrote, the output signals are assigned in an asynchronous process and in some states i want that some of the outputs will keep their last assigned value. In > synchronous process this is not a problem since a flip flop is used but in > asynchronous process an inferred latches might be created. > > Those unintended latches made me open this thread, what are your recommendations to this issue? Assuming you really want to start editing the output of the generated code, the way to make this work is to feed the current state into the next state. i.e. anything on the right side of your assignments in the async process needs to come from the synchronous process. If something needs to keep its current value, then you need to assign it to the flop (in the other process) that holds that previous value. Assigning it to itself creates a gated latch. -- GaborArticle: 157309
On 11/18/2014 11:02 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 > > Thank you all for your answers! > I would like to clarify- I didn't mean to combinatorial state machines, I meant to a "multi-process synchronous state machine" while the output signals and the next state are assigned in an asynchronic process and the current state is assigned in a synchronous process, i understand that this kind of state machine is defined as synchronous state machine. I'm not experienced with that kind of state machines as in the past I have always used one clocked process in my state machines but in my new job I'm obliged to use the HDL designer graphical tool which generates those "multi-process synchronous state machine". Now, as i wrote, the output signals are assigned in an asynchronous process and in some states i want that some of the outputs will keep their last assigned value. In > synchronous process this is not a problem since a flip flop is used but in > asynchronous process an inferred latches might be created. > > Those unintended latches made me open this thread, what are your recommendations to this issue? If your output has state that means it is part of the state logic rather than the output. If you need to "hold" an output while the rest of the state machine has moved on, you are not separating the state from the output. I believe this is the difference between a Mealy and a Moore machine. In the Moore machine the output is only a function of state. In a Mealy machine the output is a function of both the state and the input. But in neither case is the output a function of the output. So if you are getting latches in your output combinatorial logic it is because you either didn't code it correctly or you didn't specify it correctly. Then there is a type of machine where the outputs are also registered rather than being pure combinatorial logic. In this case the logic can be coded in a synchronous process and no latch will be generated regardless. -- RickArticle: 157310
rickman wrote: > 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. > Right! > 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. > NO, that is great. I appreciate you taking the time - it's just something I always wondered. And right now, I am doing a project where it made me wonder more - how do you you make sure the interface is stable? I ended up basically burying it in a device driver so that at least CPU interrupts were off. This isn't an FPGA; it's a simulated FPGA. So I can read or write to the "memory" atomically. I was gonna do it with a mechanism like System V shared memory, but I wasn't sure this had the right ... atomicity of read/write. It smelt like a Heisenbug waiting to happen. Apologies for the inability to actually ask the question properly - but I think the salient distinction is "edge triggered" vs. "level sensitive". The rest follows from that. -- Les CargillArticle: 157311
On 11/18/2014 9:26 PM, Les Cargill wrote: > rickman wrote: >> 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. >> > > Right! > >> 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. >> > > NO, that is great. I appreciate you taking the time - it's just > something I always wondered. And right now, I am doing a project where > it made me wonder more - how do you you make sure the interface is > stable? I ended up basically burying it in a device driver so that at > least CPU interrupts were off. > > This isn't an FPGA; it's a simulated FPGA. So I can read or write to the > "memory" atomically. I was gonna do it with a mechanism like System V > shared memory, but I wasn't sure this had the right ... atomicity of > read/write. It smelt like a Heisenbug waiting to happen. > > Apologies for the inability to actually ask the question properly - > but I think the salient distinction is "edge triggered" vs. "level > sensitive". The rest follows from that. Ok, glad I could help. -- RickArticle: 157312
On 17/11/2014 09:42, rickman wrote: <snip> > 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'm surprised at that statement. Have you never used a counter or anything else related to a clock or flip-flop? Perhaps the secret with any HDL is to consider how code will be implemented in the hardware? -- Mike Perkins Video Solutions Ltd www.videosolutions.ltd.ukArticle: 157313
On Thu, 20 Nov 2014 00:50:15 +0000 Mike Perkins <spam@spam.com> wrote: > On 17/11/2014 09:42, rickman wrote: > > <snip> > > > 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'm surprised at that statement. Have you never used a counter or > anything else related to a clock or flip-flop? > > Perhaps the secret with any HDL is to consider how code will be > implemented in the hardware? > Rick was using the fairly common distinction of a "latch" to mean a transparent latch with a level-sensitive gate, and a "register" or "flip-flop" to mean a storage element that's edge sensitive. Sorry to be curt, but this thread has spun far too far off into semantics, and finally just resolved with people agreeing. We can't go back down that rabbit hole, all the rabbits have rabies and halitosis. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.Article: 157314
Hello, While I certainly do not condone piracy, and I believe Xilinx should be com= pensated for their hard work, sometimes it can be handy to run ISE without = limitations on the range of targetable devices and without having to go thr= ough the rather annoying 30-day evaluation license generation. For the purpose of disabling the license checks, install ISE 14.7 (20131013= ) and make sure to create a ~/.Xilinx/Xilinx.lic (can be empty). With a hex= editor, open /opt/Xilinx/14.7/ISE_DS/ISE/lib/lin64/libSecurity.so (md5: ba= 5974651af72b9296f76e40bc432679) and at offset 0x3EABA, which is the epilogu= e of Sec_Checkout, replace the two bytes 89 D8 with B0 42 (mov al, 0x42). The new md5 will be 3d29e8d3c00ea2bb5beb406bcb9df95d. This effectively bypa= sses te license verification, and restrictions on targetable devices will b= e lifted. --rwrArticle: 157315
On Thursday, November 20, 2014 2:43:56 PM UTC-5, rwr...@gmail.com wrote: > Hello, > > While I certainly do not condone piracy So you don't condone piracy, but you enable it instead? Or am I missing something?Article: 157316
On 20/11/2014 00:58, Rob Gaddi wrote: > On Thu, 20 Nov 2014 00:50:15 +0000 > Mike Perkins <spam@spam.com> wrote: > >> On 17/11/2014 09:42, rickman wrote: >> >> <snip> >> >>> 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'm surprised at that statement. Have you never used a counter or >> anything else related to a clock or flip-flop? >> >> Perhaps the secret with any HDL is to consider how code will be >> implemented in the hardware? >> > > Rick was using the fairly common distinction of a "latch" to mean a > transparent latch with a level-sensitive gate, and a "register" or > "flip-flop" to mean a storage element that's edge sensitive. It may be a common distinction among many, but latches in FPGA parlance is generally any circuit or code that retains a signal (or level). Intended or otherwise. I also accept that transparent latches are not used as often as any other type of 'latch', but there are times when it prudent to use a "Write Enable" in its intended manner. -- Mike Perkins Video Solutions Ltd www.videosolutions.ltd.ukArticle: 157317
On 11/20/2014 8:50 PM, Mike Perkins wrote: > On 20/11/2014 00:58, Rob Gaddi wrote: >> On Thu, 20 Nov 2014 00:50:15 +0000 >> Mike Perkins <spam@spam.com> wrote: >> >>> On 17/11/2014 09:42, rickman wrote: >>> >>> <snip> >>> >>>> 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'm surprised at that statement. Have you never used a counter or >>> anything else related to a clock or flip-flop? >>> >>> Perhaps the secret with any HDL is to consider how code will be >>> implemented in the hardware? >>> >> >> Rick was using the fairly common distinction of a "latch" to mean a >> transparent latch with a level-sensitive gate, and a "register" or >> "flip-flop" to mean a storage element that's edge sensitive. > > It may be a common distinction among many, but latches in FPGA parlance > is generally any circuit or code that retains a signal (or level). > Intended or otherwise. > > I also accept that transparent latches are not used as often as any > other type of 'latch', but there are times when it prudent to use a > "Write Enable" in its intended manner. Can you tell us about the last time you used a latch rather than a register? -- RickArticle: 157318
Hi rwr, rwr.4f4@gmail.com wrote: [] > While I certainly do not condone piracy, and I believe Xilinx should > be compensated for their hard work, sometimes it can be handy to run > ISE without limitations on the range of targetable devices and without > having to go through the rather annoying 30-day evaluation license > generation. just to get the nomenclature straight: 1. piracy: the act of reproducing someone's else (art) work without permission 2. copyright infringement: unauthorized used of a copyrighted material. 3. license: set of permission granted by the licensor to the licensee to use a product. By doing what you are doing you are certainly not promoting piracy, since there's no reproduction of any artwork in your 'advise'. On the contrary you are suggesting you have more rights than the ones the licensor (Xilinx) gave you in the license. (I recall you that you accepted the license the very same moment you decided to use their software). The reason why Xilinx issues the license the way it does and copyrights their products that way is because they consider that 'running ISE without limitations' is affecting negatively their business and they want to protect it. If you really believe you have the rights to 'run ISE without limitations' you can post your name and address so that any Xilinx representative here on the group may get in touch with you and kindly explain what are your rights and what are theirs. Or maybe you can simply give them a call and see what they think. That being said, I strongly discourage anyone in this group to follow such practices and stand against such advices. OTOH if the OP wants to work hard on a GPLed toolchain for fpgas in order to really be able to *run it without limitations*, I'd be more than happy to promote and contribute to that effort. AlArticle: 157319
>> It may be a common distinction among many, but latches in FPGA parlance is generally any circuit or code that retains a signal (or level). Intended or otherwise. that would mean a register is a latch. I don't think this is the most common definition (even though it is used sometimes). Wikipedia quotes the following paragraph "Sometimes the terms flip-flop and latch are used interchangeably, but there is a distinction. A latch is transparent during a positive clock, whereas a FF is only transparent during a brief interval during the clock transition (edge)." from http://rfic.eecs.berkeley.edu/ee100/pdf/lect24.pdf which is consistent with my understanding (this isn't supposed to prove anything, just my opinion). --------------------------------------- Posted through http://www.FPGARelated.comArticle: 157320
On Fri, 21 Nov 2014 01:50:48 +0000
Mike Perkins <spam@spam.com> wrote:
> On 20/11/2014 00:58, Rob Gaddi wrote:
> > On Thu, 20 Nov 2014 00:50:15 +0000
> > Mike Perkins <spam@spam.com> wrote:
> >
> >> On 17/11/2014 09:42, rickman wrote:
> >>
> >> <snip>
> >>
> >>> 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'm surprised at that statement. Have you never used a counter or
> >> anything else related to a clock or flip-flop?
> >>
> >> Perhaps the secret with any HDL is to consider how code will be
> >> implemented in the hardware?
> >>
> >
> > Rick was using the fairly common distinction of a "latch" to mean a
> > transparent latch with a level-sensitive gate, and a "register" or
> > "flip-flop" to mean a storage element that's edge sensitive.
>
> It may be a common distinction among many, but latches in FPGA parlance
> is generally any circuit or code that retains a signal (or level).
> Intended or otherwise.
>
> I also accept that transparent latches are not used as often as any
> other type of 'latch', but there are times when it prudent to use a
> "Write Enable" in its intended manner.
>
>
> --
> Mike Perkins
> Video Solutions Ltd
> www.videosolutions.ltd.uk
Any time a synthesis tool has ever thrown a warning about "inferred
latches", it's talking about transparent latches being accidentally
generated inside of combinational code. It doesn't warn me about the
thousands and thousands of registers that I've put enables on in the
same design, just about
MUX: process(all)
begin
if sel = "00" then
Y <= A;
elsif sel = "01" then
Y <= B;
elsif sel = "10" then
Y <= C;
end if;
end process MUX;
--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.
Article: 157321On Saturday, November 8, 2014 7:06:34 PM UTC-8, stefano....@gmail.com wrote= : > Hi, I would like to create a project with FPGA.=20 > I would like to begin with a starter kit, not too expensive, <200$, but I= would like to have the possibility to communicate using ios @ 1.2V. > Which system do you suggest me? One option is to use Xilinx 7 series FPGAs. And especially if you have expe= rience with microcontrollers, Zynq is an excellent choice. It gives you dua= l ARM cores and FPGA on the same chip with 1.2V IO thrown in. Try the following for inexpensive options: http://digilentinc.com/Products/= Detail.cfm?Prod=3DZYBO http://www.amazon.com/Adapteva-P1601-DK03-Parallella-16-Desktop-Computer/d= p/B0091UD6TM/ref=3Dsr_1_1?ie=3DUTF8&qid=3D1416609614&sr=3D8-1&keywords=3Dpa= rallellahttp://www.amazon.com/Adapteva-P1601-DK03-Parallella-16-Desktop-Com= puter/dp/B0091UD6TM/ref=3Dsr_1_1?ie=3DUTF8&qid=3D1416609614&sr=3D8-1&keywor= ds=3Dparallella www.dspia.comArticle: 157322
There were and there are tools to decrypt Xilinx and Altera IP cores, so they become regular HDL files. I doubt nobody knew that in this group...Article: 157323
Dear all, agreeing with alb, this is a license breach issue and not promotion of pira= ting acts. > By doing what you are doing you are certainly not promoting piracy,=20 > since there's no reproduction of any artwork in your 'advise'.=20 >=20 > On the contrary you are suggesting you have more rights than the ones=20 > the licensor (Xilinx) gave you in the license.=20 I agree; there is no other point to be made here; accepting a license for a= licensable work is a binary decision. > OTOH if the OP wants to work hard on a GPLed toolchain for fpgas in=20 > order to really be able to *run it without limitations*, I'd be more=20 > than happy to promote and contribute to that effort. It would be great to see such an effort that many of us would contribute. I= f you are looking into a logic synthesis open-source project with a lot of = potential, I would suggest YOSYS (http://clifford.at/yosys/) by Clifford Wo= lf. Clifford does a great job in filtering out multiple and contradicting u= ser proposals and I think the project progresses well. On some aspects, it = is already commercial-grade work. Best regards Nikolaos Kavvadias http://www.nkavvadias.comArticle: 157324
On Thursday, November 6, 2014 3:58:05 PM UTC-8, Ron Aikins wrote: > I've read much on this topic elsewhere, but I'm confused on some things, = not to mention some of what I've read is out of date w.r.t. s/w versions, e= tc. I've been frustrated on a previous attempt to get things going, but am = now starting with a fresh OS installation and hope to resolve compatibility= issues up front. >=20 > So, I'm running Ubuntu 14.04 and have downloaded but not yet installed Xi= linx LabTools 14.7. I also have the infamous usb-driver-HEAD.tgz from http:= //rmdir.de/~michael/xilinx/ but have not yet installed it. >=20 > First, my OS is 64-bit. In spite of that, do I need to install the 32-bit= version of LabTools to be compatible with the usb-driver? From what I've r= ead, it doesn't sound as though there is a 64-bit version of the driver. Is= that true? >=20 > I'm not sure what runs with what, but need to find out what to do to get = this running. >=20 > Would be nice to find a "current" list of installation instructions... >=20 > Thanks, > Ron I have found recently that I didn't need to install that USB driver anymore= . You should only have to copy the firmware .hex files to the correct place= (usually from your Xilinx installation /bin/lin to /usr/share or wherever = you choose to have them in your .rules file) and install xusbdfw.rules to /= etc/udev/rules.d and restart udev. The syntax and capitalization sometimes = need minor adjustments depending which Linux distro you are using. It's bee= n a while since I messed with this but at some point along the line I reali= zed this and stopped grabbing and building that USB driver from source.
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