5 ms·

Two big questions 1. Can it do cycle accurate simulation of multiple clock domains? 2. Can it reuse the verification IP after the design is converted to Veril

Two big questions 1. Can it do cycle accurate simulation of multiple clock domains? 2. Can it reuse the verification IP after the design is converted to Verilog/VHDL?

Ericson2314 11y ago
1. So I've actually never used multiple clock domains with/ CLaSH. [The inverted clock I mentioned went to the RAM megafunction, which was instantiated in Verilog. For testing purposes my RAM (in CLaSH) had zero-cycle-delay reads, which is what the RAM w/ phase-shifted clock was supposed to simulate. Also the circuit topology is the same either way (but for the inverter on the clock), just the circuit "works" for different reasons, and thus the timing is different.] I don't quite know what you are asking, but I think/hope the answer is yes. See https://hackage.haskell.org/package/clash-prelude/docs/CLaSH-Signal-Explicit.html#g:4 https://hackage.haskell.org/package/clash-prelude/docs/CLaSH... 2. The QuickCheck testing infrastructure I wrote is all nonconvertible. But CLaSH has support to make testbenches. Like I said, I never used it because QuickCheck is oh so awesome, and undergrad projects are small, but see - https://hackage.haskell.org/package/clash-prelude/docs/CLaSH-Prelude-Testbench.html https://hackage.haskell.org/package/clash-prelude/docs/CLaSH... - https://hackage.haskell.org/package/clash-prelude/docs/CLaSH-Tutorial.html#g:7 https://hackage.haskell.org/package/clash-prelude/docs/CLaSH... Note that the testBench code works in Haskell too.
- gluggymug 11y ago
  I ask about clock domains because you stated real world designs are by and large synchronous. The issue is when we have data crossing clock domains we have a potential area for bugs dependent on the possible combinations of clock speeds. It becomes effectively asynchronous because we need to determine when data from one clock domain arrives relative to the edge of the other clock. I can't understand the Haskell stuff you are linking to. I don't know whether it is capable of finding the issues I am talking about. The second question was just trying to figure whether CLaSH can be used with Verilog/VHDL in some way. I was hoping against hope that there was a usable aspect to it in industry. I can't figure out whether there is though. The Haskell aspect is not a sweetener. We don't usually study that and it doesn't look good. You think VHDL looks bad but I think Haskell looks bad. It's like saying you've been real keen on a new beer made from brussel sprouts. 10 years ago, people were going on about SystemC. It didn't really catch on and it was a lot more normal looking.
  - Ericson2314 11y ago
    Ok, yeah sorry the docs other than the tutorial assume some familiarity with Haskell. 2. What do you mean by "verification IP"? It was that phrase that made me mention testbenches. Basically, while CLaSH is hard coded to understand certain types such as the Signal type, almost all primitive function are just defined with Verilog/VHDL templates which it instantiates. One can write their own templates that work just the same way. So for any piece of CLaSH-compilable Haskell, you get VHDL/Verilog for free, and for any bit of piece of VHDL/Verilog, you can use it in CLaSH by writing some Haskell (with the same ports, and that hopefully does the same thing) and then telling CLaSH the Haskell is to be replaced with your Verilog/VHDL. This is about as good bidirectional comparability as one can get. Automatic Verilog/VHDL -> CLaSH compilation would be an improvement, but I don't think it is possible: I'm not sure to what degree the semantics of Verilog/VHDL are formalized, and even if they are, there's no way the implementations all respect those semantics. The testbench functions are just templated like any other primitive function. 1. UnsafeSynchronizer "casts" one signal to another -- it's compiled to a plain net in Verilog/VHDL. At each output cycle, n, it looks at the round(n*fin/fout) input cycle and give it that value. Obviously this is unsafe because, as you say, in the real world the problem is asynchronous. You don't know the exact frequency ratios and phase differences, nor are they constant, and even if you did you'd get subtle timing errors with an incoming value that doesn't change on the clock edge. The trick is it is a pretty basic "black box" to augment CLaSH with, so proper synthesizers can be written in pure CLaSH. if that's not enough for some super-asynchronous synchronizer design, one can always fall back on writing their own black-box as described above. ------------------------------------------------------------------------------------------------------------ I don't think anyone imagines that CLaSH will be immediately understandable to someone who has never used Haskell. So no way does anyone expect the benefits will be immediately clear. So are you saying the restrictions I mention sound too onerous, or are you saying "I dunno, it looks weird"? If the former, that's perfectly acceptable, thank you for reading. If the latter, I'm sorry but this is a pet peeve of mine--we get this a lot in the function programming community. Understand that we are claiming the benefits are worth the non-trivial learning curve. If it was so damn obvious, it couldn't offer much benefit over the status quo---people would have already switched en mass and it would be the status quo. While C-esque cuteness looks nice, I agree such things are doomed to failure. The C model is easy enough to stand, but it's linearity, implicit state, and notion of control flow have nothing to do with the hardware---you can understand both models, but the compilation process is necessarily non-trivial and sufficiently "far from subjective" that many designs cannot be expressed at all, and many more must be expressed through very round about means. Functional HDLs like CLaSH have a dead-simple structural compilation model, so while they may not understand every circuit, they can express it---the compiler is near subjective but not homomorphic counting these like this SR flip-flop: \ r s -> let q = nor r q' q' = nor s q in (q, q') This compiles to exactly what it looks like, but diverges (i.e. infinite loops) under Haskell's semantics. Lastly here is a comparison of writing the same project twice (though the paper is done by the CLaSH designers) http://www.researchgate.net/profile/Jan_Kuper/publication/47936996_Comparing_CaSH_and_VHDL_by_implementing_a_dataflow_processor/links/02e7e520c06378cdbd000000.pdf?origin=publication_detail http://www.researchgate.net/profile/Jan_Kuper/publication/47...

Two big questions 1. Can it do cycle accurate simulation of multiple clock domains? 2. Can it reuse the verification IP after the design is converted to Verilog/VHDL?

Ericson2314 11y ago

1. So I've actually never used multiple clock domains with/ CLaSH. [The inverted clock I mentioned went to the RAM megafunction, which was instantiated in Verilog. For testing purposes my RAM (in CLaSH) had zero-cycle-delay reads, which is what the RAM w/ phase-shifted clock was supposed to simulate. Also the circuit topology is the same either way (but for the inverter on the clock), just the circuit "works" for different reasons, and thus the timing is different.] I don't quite know what you are asking, but I think/hope the answer is yes. See https://hackage.haskell.org/package/clash-prelude/docs/CLaSH-Signal-Explicit.html#g:4 https://hackage.haskell.org/package/clash-prelude/docs/CLaSH... 2. The QuickCheck testing infrastructure I wrote is all nonconvertible. But CLaSH has support to make testbenches. Like I said, I never used it because QuickCheck is oh so awesome, and undergrad projects are small, but see - https://hackage.haskell.org/package/clash-prelude/docs/CLaSH-Prelude-Testbench.html https://hackage.haskell.org/package/clash-prelude/docs/CLaSH... - https://hackage.haskell.org/package/clash-prelude/docs/CLaSH-Tutorial.html#g:7 https://hackage.haskell.org/package/clash-prelude/docs/CLaSH... Note that the testBench code works in Haskell too.

gluggymug 11y ago
I ask about clock domains because you stated real world designs are by and large synchronous. The issue is when we have data crossing clock domains we have a potential area for bugs dependent on the possible combinations of clock speeds. It becomes effectively asynchronous because we need to determine when data from one clock domain arrives relative to the edge of the other clock. I can't understand the Haskell stuff you are linking to. I don't know whether it is capable of finding the issues I am talking about. The second question was just trying to figure whether CLaSH can be used with Verilog/VHDL in some way. I was hoping against hope that there was a usable aspect to it in industry. I can't figure out whether there is though. The Haskell aspect is not a sweetener. We don't usually study that and it doesn't look good. You think VHDL looks bad but I think Haskell looks bad. It's like saying you've been real keen on a new beer made from brussel sprouts. 10 years ago, people were going on about SystemC. It didn't really catch on and it was a lot more normal looking.
- Ericson2314 11y ago
  Ok, yeah sorry the docs other than the tutorial assume some familiarity with Haskell. 2. What do you mean by "verification IP"? It was that phrase that made me mention testbenches. Basically, while CLaSH is hard coded to understand certain types such as the Signal type, almost all primitive function are just defined with Verilog/VHDL templates which it instantiates. One can write their own templates that work just the same way. So for any piece of CLaSH-compilable Haskell, you get VHDL/Verilog for free, and for any bit of piece of VHDL/Verilog, you can use it in CLaSH by writing some Haskell (with the same ports, and that hopefully does the same thing) and then telling CLaSH the Haskell is to be replaced with your Verilog/VHDL. This is about as good bidirectional comparability as one can get. Automatic Verilog/VHDL -> CLaSH compilation would be an improvement, but I don't think it is possible: I'm not sure to what degree the semantics of Verilog/VHDL are formalized, and even if they are, there's no way the implementations all respect those semantics. The testbench functions are just templated like any other primitive function. 1. UnsafeSynchronizer "casts" one signal to another -- it's compiled to a plain net in Verilog/VHDL. At each output cycle, n, it looks at the round(n*fin/fout) input cycle and give it that value. Obviously this is unsafe because, as you say, in the real world the problem is asynchronous. You don't know the exact frequency ratios and phase differences, nor are they constant, and even if you did you'd get subtle timing errors with an incoming value that doesn't change on the clock edge. The trick is it is a pretty basic "black box" to augment CLaSH with, so proper synthesizers can be written in pure CLaSH. if that's not enough for some super-asynchronous synchronizer design, one can always fall back on writing their own black-box as described above. ------------------------------------------------------------------------------------------------------------ I don't think anyone imagines that CLaSH will be immediately understandable to someone who has never used Haskell. So no way does anyone expect the benefits will be immediately clear. So are you saying the restrictions I mention sound too onerous, or are you saying "I dunno, it looks weird"? If the former, that's perfectly acceptable, thank you for reading. If the latter, I'm sorry but this is a pet peeve of mine--we get this a lot in the function programming community. Understand that we are claiming the benefits are worth the non-trivial learning curve. If it was so damn obvious, it couldn't offer much benefit over the status quo---people would have already switched en mass and it would be the status quo. While C-esque cuteness looks nice, I agree such things are doomed to failure. The C model is easy enough to stand, but it's linearity, implicit state, and notion of control flow have nothing to do with the hardware---you can understand both models, but the compilation process is necessarily non-trivial and sufficiently "far from subjective" that many designs cannot be expressed at all, and many more must be expressed through very round about means. Functional HDLs like CLaSH have a dead-simple structural compilation model, so while they may not understand every circuit, they can express it---the compiler is near subjective but not homomorphic counting these like this SR flip-flop: \ r s -> let q = nor r q' q' = nor s q in (q, q') This compiles to exactly what it looks like, but diverges (i.e. infinite loops) under Haskell's semantics. Lastly here is a comparison of writing the same project twice (though the paper is done by the CLaSH designers) http://www.researchgate.net/profile/Jan_Kuper/publication/47936996_Comparing_CaSH_and_VHDL_by_implementing_a_dataflow_processor/links/02e7e520c06378cdbd000000.pdf?origin=publication_detail http://www.researchgate.net/profile/Jan_Kuper/publication/47...