Why doesn't this situation generate a latch?
in [FPGA]
|
Prev: Some Active-HDL questions
Next: Call for Papers Reminder (extended): The World Congress on Engineering WCE 2010
From: glen herrmannsfeldt on 10 Mar 2010 15:08 In comp.arch.fpga Peter Alfke <alfke(a)sbcglobal.net> wrote: (snip) > I do not want to belabor the advantages of either design, > just to avoid confusion. > The flip-flop or register is the prevalent design. It wins the Oscar > in most (but not all) cases..., but RAM cells always use the simpler > latch structure. To be more specific, SRAM. Now, are there more SRAM cells around than registers bits in processors? If you count SRAM in processor cache memory it might be that there are more. For the first digital logic class I had, all the classroom demonstrations were done with paired RS flip-flops and a two phase clock. It does make it easier to understand in a classroom setting. Also, many past processors did use a two (or more) phase clock. (I remember stories about the four phase clock for the TMS9900.) It would be interesting to have an FPGA with transparent latches after each LUT instead of the current edge triggered FFs. -- glen
From: Peter Alfke on 10 Mar 2010 15:19 On Mar 10, 12:08 pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: > > It would be interesting to have an FPGA with transparent latches > after each LUT instead of the current edge triggered FFs. > > -- glen Glen, I simplified a little. I was frustrated by all the VHDL mumbo- jumbo. To answer your suggestion: Use Xilinx FPGAs. I know for sure that Virtex 5, and probably also 4 and 6 can configure each flip-flop as a latch, although this is a rarely-used feature. (How fast I forget such exotic facts). Peter
From: glen herrmannsfeldt on 10 Mar 2010 15:31 In comp.arch.fpga Peter Alfke <alfke(a)sbcglobal.net> wrote: (snip) > To answer your suggestion: > Use Xilinx FPGAs. I know for sure that Virtex 5, and probably also 4 > and 6 can configure each flip-flop as a latch, although this is a > rarely-used feature. > (How fast I forget such exotic facts). I didn't know that! There is discussion in another newsgroup about recreating the IBM 360/91 in an FPGA. I believe that is the machine that the Earle latch was invented for. (Maybe it was the Stretch.) The Earle latch pretty much takes one level of logic and combines it with the logic of a transparent latch. When every propagation delay counts, that helps a lot. -- glen
From: Peter Alfke on 10 Mar 2010 16:44 On Mar 10, 12:31 pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: > In comp.arch.fpga Peter Alfke <al...(a)sbcglobal.net> wrote: > (snip) > > > To answer your suggestion: > > Use Xilinx FPGAs. I know for sure that Virtex 5, and probably also 4 > > and 6 can configure each flip-flop as a latch, although this is a > > rarely-used feature. > > (How fast I forget such exotic facts). > > I didn't know that! > > There is discussion in another newsgroup about recreating the > IBM 360/91 in an FPGA. I believe that is the machine that the > Earle latch was invented for. (Maybe it was the Stretch.) > > The Earle latch pretty much takes one level of logic and combines > it with the logic of a transparent latch. When every propagation > delay counts, that helps a lot. > > -- glen Glen: from the Virtex-6 User Guide Lite: The look-up tables (LUTs) in Virtex-6 FPGAs can be configured as either 6-input LUT (64-bit ROMs) with one output, or as two 5-input LUTs (32-bit ROMs) with separate outputs but common addresses or logic inputs. Each LUT output can optionally be registered in a flip-flop. Four such LUTs and their eight flip-flops as well as multiplexers and arithmetic carry logic form a slice, and two slices form a configurable logic block (CLB). Four flip-flops per slice (one per LUT) can optionally be configured as latches. In that case, the remaining four flip-flops in that slice must remain unused. So, that says it: 4 latches per slice. Perhaps not the highest efficiency, but not too bad. PS, I am very proud of these User Guides Lite, created and published as a bootleg project, but still very popular with users. Peter
From: Andy on 10 Mar 2010 19:25
On Mar 10, 1:24 pm, Ed McGettigan <ed.mcgetti...(a)xilinx.com> wrote: > On Mar 10, 10:06 am, Andy <jonesa...(a)comcast.net> wrote: > > > On Mar 9, 12:15 pm, Ed McGettigan <ed.mcgetti...(a)xilinx.com> wrote: > > > > I would strongly encourage you to change the RESET function from > > > asynchronous to synchronous. > > > On what basis do you make this recommendation, and what does this have > > to do with latches? > > > Andy > > Synchronous versus asynchronous resets have been discussed at length > in other threads. > > Asynchronous resets have their place in a designer's toolbox, however > they should be used sparingly. Some reasons to use these are for > handshakes crossing clock domains, anticipated loss of clock and > asynchronous inputs to the synchronous domain. > > In a synchronous domain, such as the original state machine example, > the asynchronous functionality offers no additional benefit in FPGAs > as the area cost is identical for both. > > Asynchronously asserting and de-asserting a reset across multiple > registers may/will result in the registers being released before and > after a clock edge due to large net delay and skew on the reset net. > This will result in different parts of a design coming out of reset > across clock boundaries and being out of sync with each other. > > Synchronous resets simplify timing analysis and timing closure without > having to worry about the consequences of the asynchronous functions > and how to correctly constrain them. > > I often see problems with FPGA designs that are built with > asynchronous resets, but I have yet to see a problem with a FPGA > design that was traced to a synchronous reset. > > In an FPGA there is no downside to a synchronous reset, but there are > many pitfalls with an asynchronous reset. > > None of this has anything to do with a latch, which you also want to > avoid using in an FPGA. > > Ed McGettigan > -- > Xilinx Inc. Given that most sources of reset signals are not already synchronized to the clock domain(s) that need resetting, both asynchronous and syncrhonous resets require at least the deasserting edge to be synchronized. Proper syncrhonization for each case takes the same amount of design effort and resources. I will agree that getting the constraints set to make sure that the synchronous deassertion path meets timing in an asynchronously reset system can be non-obvious, but that is a tools issue, not a design issue (in other words, fix the tools!) Given that an asynchronous reset reliably resets the circuit, regardless of the presence or stability of the clock signal, when an asynchronous reset is correctly designed, it is a more reliable reset than a synchronous one. Andy |