Live data from Hacker News

How to Write Safe Verilog: Become a PL Troll

danluu.com

11–20 of 53 posts

Re: How to Write Safe Verilog: Become a PL Troll

#11
post #3

"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.

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+

Just to clarify a bit: It takes time to go through combinational logic (AND and OR gates, etc.) and your clock has to go as slow as the slowest path to ensure that the signals are all correct at the same time. Registers are the start- and end-points of a combinational path, so placing a register in the critical path can increase your clock speed. However, that means that the data isn't available on the other side of the register until the next clock cycle.

Re: How to Write Safe Verilog: Become a PL Troll

#12
post #10

Earlier quoted context omitted.

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+

> 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?

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

Re: How to Write Safe Verilog: Become a PL Troll

#13
In high speed designs, it’s an error to use a signal that’s sourced from another module

Not sure if I agree here, at least in these absolute terms. Sometimes you cannot afford to unnecessarily capture every I/O signal, and it is indeed not always necessary.

Re: How to Write Safe Verilog: Become a PL Troll

#14
post #8

As someone who spends 40 hours a week (and 60 - 70 lately) coding Verilog for FPGAs I'm always excited when something domain-specific hits the front page. I have no idea what a PL Troll is, though, so I think I missed the point of the entire post. Anyone care to elaborate? Google is not helpful.

You might enjoy a new hardware description DSL from our lab: https://chisel.eecs.berkeley.edu/ :)

Re: How to Write Safe Verilog: Become a PL Troll

#15
post #10

Earlier quoted context omitted.

> 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?

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

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.

Re: How to Write Safe Verilog: Become a PL Troll

#16
post #15

Earlier quoted context omitted.

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

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…

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

Re: How to Write Safe Verilog: Become a PL Troll

#18
post #3

"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.

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.

Re: How to Write Safe Verilog: Become a PL Troll

#19
post #18
post #3

"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.

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…

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.

Re: How to Write Safe Verilog: Become a PL Troll

#20

This is a fascinating glimpse into a world I know less than nothing about. I don't anticipate ever needing to code in Verilog, but I'll try to keep this in mind and look for other places where a little effort can save a lot of time. I wonder what this has to say about type systems in general. Projects like Clojure's core.typed let you add static typing as a library where you feel like you need it, but then you don't…

It's a fascinating glimpse into his old company design methodology, and according to linkedin that company is VIA and the chip may be an X86.

Sorry for the stalking but you must realize you posted in a site called "hacker news"

Post reply on HN