Forum Discussion
Altera_Forum
Honored Contributor
14 years agoWow. Definitely a lot of work. I haven't had a chance to read the whole thing(traveling for work this week and trying to finish up a number of things), but some quick thoughts:
1) The register example concerns me in that the FPGA design is input -> reg -> output. As you're example shows, you're really forced to balance the input delays and the output delays. The thing is that most designs are input -> input_reg -> logic with many register levels -> output_reg -> output Because of the logic inside, the input timing and output timing do not directly work against each other. Now, for the design that is setup like yours, it's a good example, but usually there would be some soft of logic too(a decode, mux, etc.), as just registering the data and sending it out again doesn't do much. I know you're doing it as a timing example and don't want to add logic to confuse, but my point is that adding logic will make the design more complex, i.e. if the logic is before and/or after the register, that will complicate timing even more. But I guess the main point is that, as a generic example, the fact that there is only one register deviates from most designs. 2) Asynchronous RAMs are a pain. The recipe I follow is to treat the output and input side almost as if constraining between two different FPGAs. I generally do something like the following: - Create a virtual clock. - Constrain the address going off chip as tight as possible. That means first putting in a -max delay and increasing it to the point it doesn't fail. That means the output timing is as quick as possible. Then add in a -min value to catch the other side. You now have a Tco max and min for the address going out. - Add those values + the max and min round-trip external delays through the SRAM and across the board. This is the external delay for the set_input_delay on the data. (If you are taking multiple cycles to do a read, then multicycles may be necessary). That covers the read side. The write side is treated like any source-synchronous interface, except the WRITE strobe is treated as a clock.