Re: Newbie frustration

KJ wrote:

Daniel O'Connor wrote:
Many times this symptom is a result of a timing violation. Check that
the setup time and the clock frequency as reported by the place and
route timing report is being met by whatever simulation model you have
driving the design.

Yup, the requirements at the basic level are fairly modest, and my timing
constraints are being met.

Also, check the list of warnings that pop out of the synthesis to look
for things that you shouldn't try to do in an FPGA. If you find them,
you'll probably need to get rid of them. Things like...
- Transparent latches
- Generating your own internal clocks (can be done, but only with
care).

I need to generate an internal clock :(
Any tips on how to do it properly?
Hmm actually I can rejig the design to use an enable which is probably the
right thing to do.

- Other warnings that pop out should also be perused to make sure you
understand why it is a warning and if this is a concern in your design.
As with software, many times a compile time warning is a run time (or
in your case timing simulation) error.

I have had an odd one which does not appear affect the final result - I have
a right shifter with a lookup table in front (for compatibility reasons) so
I do..
module shifter(DIN, SHIFT, DOUT);
output [15:0] DOUT; // Data out

input [31:0] DIN; // Data in
input [3:0] SHIFT; // Amount to shift by (sort of)

reg [15:0] DOUT;
reg [31:0] TMPOUT;
reg [3:0] SHIFTp;

always @(DIN or SHIFT) begin
case (SHIFT)
4'd13: // 8192 integrations (not possible in the old SA)
SHIFTp = 13;
4'd14: // 16384 integrations (not possible in the old SA)
SHIFTp = 14;
4'd15: // 32768 integrations (not possible in the old SA)
SHIFTp = 15;
4'd12: // 0/1 integrations
SHIFTp = 0;
4'd11: // 2 integrations
SHIFTp = 1;
[...]
endcase // case(SHIFT)

TMPOUT = DIN >> SHIFTp;
DOUT = TMPOUT[15:0];
end // always @ (DIN or SHIFT)
endmodule // shifter

This synthesises to a ROM table and a shifter which is what I want. However
xst warns me that SHIFTp and TMPOUT are assigned but never used. I presume
that it optimised them away or something.

It also complains that SHIFTp is not in the sensitivity list of the always
block.. Seems rather odd to me..

Strangely I find that the results are fine but the final FIFO is either
not clocking the data in properly, or not clocking it out properly..

This might be a clue as to where timing is being violated. Since this
was from an 'old' board I'm guessing that the FIFOs there were the
garden variety async FIFOs. Hopefully inside the FPGA you didn't try
to implement that but used a standard synchronous type instead.

Yes they're async - IDT 720x.

I am using the async FIFO core from Xilinx's coregen (and an ALU).

However if I test it in isolation it works fine.
When you're testing it in isolation though I'll bet that the timing in
and out of the FIFO is not really the same as it is when inside the
full FPGA. When testing in isolation, if you were to apply stimulus at
the exact same time to this isolated FIFO it would not work in the same
manner as you're seeing it not work for you now.

Hmm OK..
What a pain :)

If it is a synchronous FIFO then are the clocks free running or gated?
If gated, then how that gating logic is implemented could be the
problem (once again though, this is just a manifestation of a timing
failure which can also be caught by full static timing analysis).

It is an async core, although the clock signal is not free running, it is
generated off the card by a PLD which is gating another clock.
Unfortunately I can't change that aspect :(

Based on my reading of the data*** I don't think that is a problem as such
because the only problem I would have is that the flags won't get updated,
but this design does not use them.

I have applied some basic timing constraints, and when looking at the
resulting timing diagrams it seems that there is plenty of time for the
data to be valid on the input side of the final FIFO before the write
clock is applied.

What about all the timing inside of the device though? What is the
timing report telling you there? If there are multiple clocks involved
then moving data from one clock domain to the other needs to be done
properly.

The thing is that the "clocks" aren't free running at all, they're all
derived from the same base clock and gated with a PLD (or 3) and then piped
down the backplane to the card I am designing.

So I think in practise I am not actually going from one clock domain to
another..

I captured some sample signal information and have been using that as my
test suite. In it, the control signals for the final FIFO where I am seeing
the problem the data is clocked in and then clocked out later - at no time
are both sides of the FIFO being clocked..

I'm about to see if there is a way to peer inside the FIFO black box so I
can tell if it's the read or write side that is at issue.

Thanks for your reply!

--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
.

Loading