Accelerate design performance

Question

Hi,

I found a very interesting White Paper from Xilinx "HDL Coding Practices to Accelerate Design Performance" (WP231, you have to search it yourself because I'm not allowed to post links...), detailing very nicely some coding hints to get a good performance out of the RTL description.

This WP is of course applicable to Xilinx devices and I'm unsure if any of this can be translated to Altera devices/Toolchain. Does anyone know of a similar paper written for Altera FPGAs?

Cheers,

Andreas

ps.: [main xilinx page]/support/documentation/white_papers/wp231.pdf

altera_forum · Answer

Ahhh... I've heard X recommends making resets synchronous, and this might finally explain why. A quick perusing of their document, and I think everything else holds true for Altera, but I do know Altera recommends an asynchronous reset for performance, sinc the asynchronous input is a dedicated input, and basically wasted if you make your reset synchronous. More importantly, the reset will now use a synchronous input that could have been used for synchronous logic.

In general, I strongly recommend using the aysnchronous assert/synchronous de-assert reset circuit. It uses the asynchronous input of the register. The way it's designed allows it to assert asynchronously, so if the system clock disappears the device can still be reset to a good state rather than being stuck in it's current state(useful if your design, say, controls the acceleration of a car). But it de-asserts synchronously insuring that every register in the domain comes out together and start toggling together every time out of reset(this is probably one of the main things I've seen people having to debug after shiiping product, recovery and removal failures.) This circuit is described in more detail at:

http://www.alteraforum.com/forum/showthread.php?t=5026&highlight=recovery

altera_forum · Answer

The synchronous reset recommended by Xilinx seems to be a combined Toolchain+Device issue. If the RTL is ideal, ISE is able to optimise perfectly in some cases.

I think it's very likely that similar optimisations are possible for Quartus+Altera Device but I was unable to find a document about it.

altera_forum · Answer

Rsyc, did you mean that you strongly recommend the sync assert/async de-assert scheme, rather than strongly recommend against it?

altera_forum · Answer

Thanks.  I just fixed it in the original post.  But yes, I strongly recommend using it.  Probably the most important part is the synchonous de-assert.  This confuses many people at first(including myself), since it's an asynchronous signal.  I've debugged enough field failures to realize how important this is.  As for the asynchronous assert, it makes sense.  There are certainly applications where it doesn't matter, i.e. if you're making a hand-held video game and the board clock goes bad, you don't care if you can reset it to a known good state, you just throw it away(although if the clock goes bad while making a loud noise, it's not a good situation).  But I think the practive still makes sense.  And in Altera devices, you get better results by using the asynchronous reset, since it's a wasted resource if you don't.  (The difference usually isn't too big, but enough to notice).

altera_forum · Answer

I strongly agree with Rysc about connecting reset to the dedicated port.

The confusion comes from the terminology:

data passess from reg to reg and needs be synchronised at each stage.

but reset comes from a source and ends at every reg.

reset thus is synchronised at source and need not be resynchronised at reg.

In other words it is always applied pre-synchronised.

Forum Discussion

Accelerate design performance

5 Replies

Recent Discussions

Cyclone 5 SoC FPGA Bank Supply Prerequisite

AGILEX 5 Migration issue

To INTEL - Request for Compliance Data from Analog Devices, Inc

Arria 10 GX RX max intra-differential pair skew

MAX10 Bitstreams Authentication