Newbie frustration

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.

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).

- 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.

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.

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.

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).

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.

KJ

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

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.

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..

Yes they're async - IDT 720x.

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

Hmm OK.. What a pain :)

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 datasheet 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.

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!

Hi, One thing that looks a little suspect - the lines:

TMPOUT = DIN >> SHIFTp; DOUT = TMPOUT[15:0];

are inside the always statement - and as shiftP is on the right hand side, it should be in the sensitivity list. I think moving these two lines outside, and making them assign statements will get rid of your synthesis warning - as to what logic is actually being produced - hard to say! but I'd imagne that this construct would make behavioural different from post synthesis in simulation. Hope this helps,

Cheers John

Daniel O'C>

But SHIFTp and TMPOUT are entirely generated inside the always statement so I wouldn't think it is necessary.. (Is my C programmer heritage showing yet?)

Well the problem is that module seems to work :) If I do a post-PAR simulation it gives me the result I expect, and the RTL schematic for that section is exactly what I'd expect, ie

SHIFT[3:0] ---> ROM --- >Right Shift ---> DOUT[15:0] ^ | DIN[31:0] -----------------+

Unfortunately they are the only synthesis errors I see (that aren't generated by the coregen code), so I guess I'll have to do more looking into timing issues :)

Hi Daniel, You are right - they are totally contained within that always block - so you most likely are getting away with it - but if you had used noo-blocking yet?)

True enough, but I've been trying to commit the "Verilog coding styles that kill" paper to memory so I didn't use non blocking statements :)

Sort of - I think really it would just hide the bugs in Xst. (but the price is right so I'm not complaining very much :)

More's the pity really 8-)