--- Quote Start ---
Wow. 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)
--- Quote End ---
Thanks for taking the time to respond!
--- Quote Start ---
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.
--- Quote End ---
Yeah, the example is really there as a tool intro. I have another example that has input registers, fabric registers, and output registers. That allows Fast I/O register constraints to be applied at both ends. I'll add that to the next version of the document.
--- Quote Start ---
2) Asynchronous RAMs are a pain.
--- Quote End ---
Ah-ha! A quote for my document ... :)
--- Quote Start ---
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.
--- Quote End ---
Ok, so the method of constraining the interface is a hack ... not a problem ... its just not in any 'recommended practices' document ...
Thanks for these initial thoughts! If you have any other tool hints, I'd like to add those too.
Cheers,
Dave
Honored Contributor
