4 ms·

As an hardware engineer, I'm always skeptical of these homebrewed high level design flows, they usually never seem to translate to good hardware. And it seems

by sweden 8y ago

As an hardware engineer, I'm always skeptical of these homebrewed high level design flows, they usually never seem to translate to good hardware. And it seems to be the case for this one too. I quickly generated some Verilog code from one of the given examples and I was surprised to see flip-flops without reset. Also, not all registers are even being reset'ed at all. I have some serious doubts about the quality of the hardware generated by this tool.

TomVDB 8y ago
The presence or lack of a reset on a FF isn't exactly the best proxy for hardware quality.
- sweden 8y ago
  Strange bugs can happen if the hardware is not correctly initialized and the presence of an asynchronous reset is almost an universal practice when it comes to this. Not to mention that the coding style of a always@ block might influence certain optimizations in the hardware synthesis tool. If the FF is not explicit in the code, the tool might infer a latch instead, for example. It's true that there are reasons to use use always@ blocks like the generated code provides but it's not really obvious in this case why it is being used.
  - TomVDB 8y ago
    > ... the presence of an asynchronous reset is almost an universal practice when it comes to this Using async resets isn't a great example when many modern ASIC flows shun it in favor of synchronous resets. :-) (Among other reasons, async reset will always mess up your design when you have crosstalk induced glitches; a sync reset will only do so when it coincides with a clock edge.) > Not to mention that the coding style of a always@ block might influence certain optimizations in the hardware synthesis tool. If the FF is not explicit in the code, the tool might infer a latch instead, for example. Yeah, let's just strongly disagree on that one and leave it at that.
    - sweden 8y ago
      Then both of us must be designing ASICs which are worlds apart. :-) Asynchronous resets are fundamental because they are not dependent of the presence of a working clock. Imagine that you have a system working on synchronous reset: if your entire system breaks, including the PLL which generates the clock, and you want to reset it, how are you going to do it if the clock is not working in the first place? Also, a reset signal is asynchronous by nature, if you wanted to use synchronously to your system's clock, you would need to add extra hardware to bring it to your clock domain. And this would expose it to possible metastability problems.
      - deleted 8y ago
        [deleted]
      - TomVDB 8y ago
        The arguments that you give are pretty trivial and easy to solve once and for all compared to physical design consequences (which you don’t mention at all.) They were definitely not sufficient to stop the conversion of millions of lines of Verilog from async to synchronous resets. A decision that was obviously not made lightly. Ultimately, both async and sync reset methodologies can be made to work. Using sync reset in all of today’s chips doesn’t suddenly make the async chips of 5 years ago non-functional. On an FPGA (which is the main target of this tool), it doesn’t really make a difference since there is no physical design to be done.
        sweden 8y ago
        I didn't mention physical implementation (if that's what you mean by "physical design", "physical design" is a term which would describe the process of doing a full custom design directly in schematic/layout without even using design techniques such as Verilog) because async/sync is part of the digital architecture of the hardware. I feel I don't understand what you are trying to say, you just dismissed by entire comment without address any of the things I mentioned.
        8y ago
tripletao 8y ago
No need for async reset in most FPGA flows--the flops all start at zero, or whatever you initialize them to. Adding one anyways may bloat your area, and has no benefit. (Like, if you don't trust the FPGA's own power-on-reset logic, then how do you expect it to get configured?)
- analognoise 8y ago
  This. GP's comment is way old school. For most FFs in your designs, reset is unnecessary. Ken Chapman at Xilinx wrote some wonderful whitepapers about that; look them up. Join us in enlightenment, brother.
  - sweden 8y ago
    It's not old school, it's standard practice in the ASIC design industry. You mentioned those papers but you didn't link them, so I will have to guess that this is the one in order to address your comment: - https://www.xilinx.com/support/documentation/white_papers/wp272.pdf https://www.xilinx.com/support/documentation/white_papers/wp... I guess the keyword here is "FPGA design". The author of the paper argues that the FPGA already offers an abstraction layer that allows the designer to ignore the problem for certain occasions in order to save up on area. > The good news is that 99.99% of the time, the timing of the reset release really doesn't matter. (...) However, if you have ever had one of the circuits that doesn’t work the first time, then maybe you have encountered one of the 0.01% cases and have been unlucky enough to have released the reset at the wrong time. > A design implemented in a Xilinx FPGA does not require insertion of a global reset network. For the vast majority of any design, the initialization state of all flip-flops and RAM following configuration is more comprehensive than any logical reset will ever be. There is no requirement to insert a reset for simulation because nothing will be undefined. But it doesn't mean it is 100% correct as this design would be very poor if it was ever translated to an ASIC. I guess since this project is done with FPGA design in mind, the strict ASIC design rules don't apply here.
    - tripletao 8y ago
      Not really a question of degree of correctness. Optimizing for FPGA vs. ASIC implementation are just different problems. Approaches that are optimal for one may be sub-optimal or outright wrong for the other.
aylons 8y ago
I agree with you: it pays to be skeptical of these high level design flows. I'm wary of HLS even from established vendors. However, if it targets FPGA, and not ASICs, maybe the reset omission is on purpose. FPGA guarantees initialization on load and the some registers may not need to be cleared after usage. On the other hand, a reset signal consumes precious routing resources spanning large areas. But I surely would triple-check this, even for FPGA use. I expect to actually do so in a few weeks. EDIT: Ok, this comment sit far too long in the edit box before posting. Now I see the huge discussion in this thread. I'll keep this comment anyway.

by sweden 8y ago

TomVDB 8y ago

The presence or lack of a reset on a FF isn't exactly the best proxy for hardware quality.

sweden 8y ago
Strange bugs can happen if the hardware is not correctly initialized and the presence of an asynchronous reset is almost an universal practice when it comes to this. Not to mention that the coding style of a always@ block might influence certain optimizations in the hardware synthesis tool. If the FF is not explicit in the code, the tool might infer a latch instead, for example. It's true that there are reasons to use use always@ blocks like the generated code provides but it's not really obvious in this case why it is being used.
- TomVDB 8y ago
  > ... the presence of an asynchronous reset is almost an universal practice when it comes to this Using async resets isn't a great example when many modern ASIC flows shun it in favor of synchronous resets. :-) (Among other reasons, async reset will always mess up your design when you have crosstalk induced glitches; a sync reset will only do so when it coincides with a clock edge.) > Not to mention that the coding style of a always@ block might influence certain optimizations in the hardware synthesis tool. If the FF is not explicit in the code, the tool might infer a latch instead, for example. Yeah, let's just strongly disagree on that one and leave it at that.
  - sweden 8y ago
    Then both of us must be designing ASICs which are worlds apart. :-) Asynchronous resets are fundamental because they are not dependent of the presence of a working clock. Imagine that you have a system working on synchronous reset: if your entire system breaks, including the PLL which generates the clock, and you want to reset it, how are you going to do it if the clock is not working in the first place? Also, a reset signal is asynchronous by nature, if you wanted to use synchronously to your system's clock, you would need to add extra hardware to bring it to your clock domain. And this would expose it to possible metastability problems.
    - deleted 8y ago
      [deleted]
    - TomVDB 8y ago
      The arguments that you give are pretty trivial and easy to solve once and for all compared to physical design consequences (which you don’t mention at all.) They were definitely not sufficient to stop the conversion of millions of lines of Verilog from async to synchronous resets. A decision that was obviously not made lightly. Ultimately, both async and sync reset methodologies can be made to work. Using sync reset in all of today’s chips doesn’t suddenly make the async chips of 5 years ago non-functional. On an FPGA (which is the main target of this tool), it doesn’t really make a difference since there is no physical design to be done.
      - sweden 8y ago
        I didn't mention physical implementation (if that's what you mean by "physical design", "physical design" is a term which would describe the process of doing a full custom design directly in schematic/layout without even using design techniques such as Verilog) because async/sync is part of the digital architecture of the hardware. I feel I don't understand what you are trying to say, you just dismissed by entire comment without address any of the things I mentioned.
        8y ago

tripletao 8y ago

No need for async reset in most FPGA flows--the flops all start at zero, or whatever you initialize them to. Adding one anyways may bloat your area, and has no benefit. (Like, if you don't trust the FPGA's own power-on-reset logic, then how do you expect it to get configured?)

analognoise 8y ago
This. GP's comment is way old school. For most FFs in your designs, reset is unnecessary. Ken Chapman at Xilinx wrote some wonderful whitepapers about that; look them up. Join us in enlightenment, brother.
- sweden 8y ago
  It's not old school, it's standard practice in the ASIC design industry. You mentioned those papers but you didn't link them, so I will have to guess that this is the one in order to address your comment: - https://www.xilinx.com/support/documentation/white_papers/wp272.pdf https://www.xilinx.com/support/documentation/white_papers/wp... I guess the keyword here is "FPGA design". The author of the paper argues that the FPGA already offers an abstraction layer that allows the designer to ignore the problem for certain occasions in order to save up on area. > The good news is that 99.99% of the time, the timing of the reset release really doesn't matter. (...) However, if you have ever had one of the circuits that doesn’t work the first time, then maybe you have encountered one of the 0.01% cases and have been unlucky enough to have released the reset at the wrong time. > A design implemented in a Xilinx FPGA does not require insertion of a global reset network. For the vast majority of any design, the initialization state of all flip-flops and RAM following configuration is more comprehensive than any logical reset will ever be. There is no requirement to insert a reset for simulation because nothing will be undefined. But it doesn't mean it is 100% correct as this design would be very poor if it was ever translated to an ASIC. I guess since this project is done with FPGA design in mind, the strict ASIC design rules don't apply here.
  - tripletao 8y ago
    Not really a question of degree of correctness. Optimizing for FPGA vs. ASIC implementation are just different problems. Approaches that are optimal for one may be sub-optimal or outright wrong for the other.

aylons 8y ago

I agree with you: it pays to be skeptical of these high level design flows. I'm wary of HLS even from established vendors. However, if it targets FPGA, and not ASICs, maybe the reset omission is on purpose. FPGA guarantees initialization on load and the some registers may not need to be cleared after usage. On the other hand, a reset signal consumes precious routing resources spanning large areas. But I surely would triple-check this, even for FPGA use. I expect to actually do so in a few weeks. EDIT: Ok, this comment sit far too long in the edit box before posting. Now I see the huge discussion in this thread. I'll keep this comment anyway.