4 ms·

"In high speed designs, it’s an error to use a signal that’s sourced from another module" How else are you supposed to get I/O from one module to another, say

by tcas 13y ago

"In high speed designs, it’s an error to use a signal that’s sourced from another module" 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.

CamperBob2 13y ago
To some extent his advice suffers from the same problem that many books suffer from, in that it comes from the ASIC world while a large share of Verilog work these days is probably done to target FPGAs. For reasons too long to elaborate upon here, you can get away with a lot of things on FPGAs that may not be such a good idea on ASICs.
- sliverstorm 13y ago
  you can get away with a lot of things on FPGAs... 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.
  - DigitalJack 13y ago
    True for some FPGAs. anti fuse still has a place in the industry.
sliverstorm 13y ago
How else are you supposed to get I/O... 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+
- derleth 13y ago
  > I believe the answer in this case is you latch the signal, and use a local copy. So the latch is local to both, and therefore not using a signal from another module?
  - sliverstorm 13y ago
    The latch would be local to the module. The latch captures the input, and reproduces it inside the module. Think like this: sub proc { my $latch = @_[0]; } We capture the input signal in $latch for local use in the proc
    - tcas 13y ago
      So, essentially feeding it into something like BUF? I thought those were optimized out on modern FPGAs. 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.
      - sliverstorm 13y ago
        I don't remember what a BUF represents in FPGA tools- the name implies an inverter pair, e.g. buffer, but I don't remember for sure. Anyway, I mean a sequential element, such as a latch or a flip-flop. (If you don't know what those are, please pay a quick visit to Wikipedia- they are fundamental) 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 ...) endmodule
zhemao 13y ago
Yeah, I didn't understand that first part either. A module isn't very useful unless it's connected to other modules. I think he means something different, but I can't tell what.
aortega 13y ago
Spent the last 2 years doing high-speed comm designs on FPGAs. (I don't know if 5 Gbps currently count as high speed though). The tools are quite mature and will mostly prevent you from doing stupid things. 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.
- beambot 13y ago
  Hrm... I've definitely included double-buffering on some signals to prevent metastability between clock domains. I'm not sure if ISE catches all such errors, but it was a low-resource sanity check that made me feel a lot better.
- sliverstorm 13y ago
  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.
- MichaelSalib 13y ago
  Neverd did any ASIC but I know they have about 10X the testing and simulation that FPGA have. 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.

by tcas 13y ago

CamperBob2 13y ago

To some extent his advice suffers from the same problem that many books suffer from, in that it comes from the ASIC world while a large share of Verilog work these days is probably done to target FPGAs. For reasons too long to elaborate upon here, you can get away with a lot of things on FPGAs that may not be such a good idea on ASICs.

sliverstorm 13y ago
you can get away with a lot of things on FPGAs... 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.
- DigitalJack 13y ago
  True for some FPGAs. anti fuse still has a place in the industry.

sliverstorm 13y ago

How else are you supposed to get I/O... 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+

derleth 13y ago
> I believe the answer in this case is you latch the signal, and use a local copy. So the latch is local to both, and therefore not using a signal from another module?
- sliverstorm 13y ago
  The latch would be local to the module. The latch captures the input, and reproduces it inside the module. Think like this: sub proc { my $latch = @_[0]; } We capture the input signal in $latch for local use in the proc
  - tcas 13y ago
    So, essentially feeding it into something like BUF? I thought those were optimized out on modern FPGAs. 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.
    - sliverstorm 13y ago
      I don't remember what a BUF represents in FPGA tools- the name implies an inverter pair, e.g. buffer, but I don't remember for sure. Anyway, I mean a sequential element, such as a latch or a flip-flop. (If you don't know what those are, please pay a quick visit to Wikipedia- they are fundamental) 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 ...) endmodule

zhemao 13y ago

Yeah, I didn't understand that first part either. A module isn't very useful unless it's connected to other modules. I think he means something different, but I can't tell what.

aortega 13y ago

Spent the last 2 years doing high-speed comm designs on FPGAs. (I don't know if 5 Gbps currently count as high speed though). The tools are quite mature and will mostly prevent you from doing stupid things. 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.

beambot 13y ago
Hrm... I've definitely included double-buffering on some signals to prevent metastability between clock domains. I'm not sure if ISE catches all such errors, but it was a low-resource sanity check that made me feel a lot better.
sliverstorm 13y ago
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.
MichaelSalib 13y ago
Neverd did any ASIC but I know they have about 10X the testing and simulation that FPGA have. 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.