How else are you supposed to get I/O from one module to another, say a 32bit data bus? Also, what's the definition of high speed here?
"unless you like random errors"
And very hard to diagnose errors until you realize that you messed up your clock domains.
Somewhere here I saw a comment saying that you must time your design taking in account the logic delay or will get weird errors, but that's impossible. The tool chain (both quartus and Xilinx ISE) will report the max clock speed with a big bold red font if you try to go faster.
There's a step in every design flow called DRC (Design rule-checker), basically a bunch of warnings if you do dumb things with anything including the high-speed transcievers. You must pay attention to the warnings.
Neverd did any ASIC but I know they have about 10X the testing and simulation that FPGA have. I would believe you don't get random errors if you follow the standard design flow and tests.
In ASIC, or FPGA? With FPGA, you're probably right. With ASIC, it will depend on your goals. For example, I'm not aware of an industry standard methodology for accounting for the timing impact of localized supply droop. I believe that's something you have to cook up yourself.
My spouse designs CPUs for a major CPU manufacturer (you've used them). She is responsible for physical design for one tile (there are many tiles, each of which has other physical designers). Her single tile, by itself, is substantially larger than almost all ASIC designs in the world today. At that scale, most of the standard FPGA design tools don't even work. Designing in that space is substantially different than FPGA or even ASIC design.
I believe the answer in this case is you latch the signal, and use a local copy. Sort of like how it is good practice to use local variables when coding.
what's the definition of high speed
Last I heard, 100MHz+
So the latch is local to both, and therefore not using a signal from another module?
sub proc {
my $latch = @_[0];
}
I can see the sourcing issue when trying to fan out too much from a single module, but I don't see any issue doing a high speed interconnect between them as long as you're intelligent about where the modules are going to be placed in regards to chip I/O. i.e. don't have a high speed serdes unit on one bank try and directly talk to a bank on the other side of a chip.
It is a placement/distance problem. Sometimes one module needs to talk to a module on the other side of the chip, and there's no two ways about it. In that case, when you clock it fast enough, you need to break the path across cycles.
edit: It looks like BUF is indeed the Xilinx primitive for a buffer, so no. Definitely not what I meant.
Half-cocked Example:
module test ( a, clk );
input a; input clk;
wire a; wire clk;
reg flop;
always @ (posedge clk)
begin
flop = a;
end
(... useful things ...)
endmoduleFor ASIC work there are a couple of tools used these days: http://www.cadence.com/products/mfg/tempus/pages/default.asp...
http://www.synopsys.com/Tools/Implementation/SignOff/Pages/P...
Electronic Design Automation is a tough market to crack - for most startups the exit strategy is to be bought by one of the 2 (or 3) big players without being sued by them first!
Perhaps the most important thing you can get away with? Errors. Reprogramming an FPGA takes three minutes; manufacturing a new ASIC takes three months and three million dollars (or something along those lines). So dot your i's and cross your t's, baby.