This list is for discussion of the design and implementation of field-programmable gate array based processors and integrated systems. It is also for discussion and community support of the XSOC Project (see http://www.fpgacpu.org/xsoc).
|
Is there any disadvantage to using a d-latch versus a flip-flop ? I'm double cycling a LUT ram and I want to capture the output on the falling edge of the clock, as is done for the xr16 registers. Problem is I need the output asap and it seems to me that a flow through latch would allow me to use the signal sooner than a synchronous ff. Thanx Rob http://www.birdcomputer.ca |
|
|
|
That's a classic ploy. In your case, an LD with its G pin on the global clock net, open in the first half of the cycle, seems OK, assuming everything before and after is rising-edge-triggered FFs, at least sitting here on a Saturday night. Managing the worst case interconnect delays in an FPGA to use latches properly is usually nearly impossible. Make certain that your design is safe assuming min and/or max delays. Anything less is asking for trouble. Even then, the design may not be portable to other FPGAs, even other timing grades of the same FPGA. I follow conservative practice and never use latches myself. Your case might indeed be a safe exception, but be careful. --Mike wrote: > > Is there any disadvantage to using a d-latch versus a flip-flop ? I'm > double cycling a LUT ram and I want to capture the output on the > falling edge of the clock, as is done for the xr16 registers. Problem > is I need the output asap and it seems to me that a flow through > latch would allow me to use the signal sooner than a synchronous ff. > > Thanx > Rob > http://www.birdcomputer.ca > > To Post a message, send it to: > To Unsubscribe, send a blank message to: |
|
|
|
Good thinking. I have gone down that path myself. Note two things. 1. In the XC4000-derived architectures, the LUT RAM and the FFs-or-latches have independent clock inversions, so within a single CLB you can write into the RAMs on the clock rising edge and capture or latch the RAM outputs on the falling edge. No such luck in Virtex-derived architectures including Spartan-II. There, there is only a common clock inversion for both LUT RAM and FFs, and if you write into the RAMs on a rising edge, you can only clock the FFs on the rising edge, and (as far as latches) they close on the rising edge too. So you can't clock the FFs/latches on the other edge as with xr16 on XC4000. If you want to, you have to put the FFs/latches in another column of CLBs, and the extra interconnect delays hurt. 2. There was a serious, glaring bug in the Xilinx tools for Virtex with respect to clock inversion between the LUT RAM and the FFs/latches, which led good-intentioned designers down a garden path. Read all about it here: http://groups.google.com/groups?hl=en&lr=&safe=off&ic=1&th=f95136ce34358fc3, 11. Jan Gray, Gray Research LLC |
|
|
|
Thanks for the heads-up. I would not have found that problem until I tried to run things in hardware. I guess I'll have to rework my design a little bit. Does the same problem exist in Webpack ? Rob http://www.birdcomputer.ca/ |
|
|
|
Jan Gray wrote: > > I don't know if the same problem occurs in WebPack (or what version > thereof). > > An alternative solution may be to clock the register file 'output register' > FFs (only) with a 2X clock, possibly derived from a DLL. Depending upon > your design, this may simply consume a global clock net that you weren't > using anyway, plus some power to distribute the 2X clock. Using Altera Software,I found trying to use 2x clock is near impossible with a similar problem. The software has no idea what clock you are using and calculates the longest delay, rather than what you expect as delays. You could still end up with a slower design as clock enables take up routing and could force more logic cells to be used. Ben. |
|
I don't know if the same problem occurs in WebPack (or what version thereof). An alternative solution may be to clock the register file 'output register' FFs (only) with a 2X clock, possibly derived from a DLL. Depending upon your design, this may simply consume a global clock net that you weren't using anyway, plus some power to distribute the 2X clock. Jan Gray, Gray Research LLC |
|
|
|
> An alternative solution may be to clock the register file 'output register' > FFs (only) with a 2X clock, possibly derived from a DLL. Hey, I thought of that too. I'm actually clocking both the register file and output ff's using the same 2X clock now so I can keep things in the same slice. I gate the write enable to the regs using a phase shifted 1X clock so they are only updated on the second 2X clock pulse. I'm also trying to use the enable signal on the ff's to time when they get clocked like this: always @(posedge clk2f or posedge reset) begin if (reset) begin aa <= 0; cc <= 0; end else begin if (clk90) begin aa <= rfab_out; cc <= rfct_out; end end end Don't know if it will work or not. I have'nt taken a serious look at the output yet because I'm still in the design stage. Rob http://www.birdcomputer.ca/ |