Ask HN: Cryptographic timestamp? - <AUTHOR>

I have a few dozen ideas for various inventions and algorithms that are potential game changers but probably too big for me to pull off myself.  So I would like to post them to my website and sign them somehow to prove that they were released on a specific date for prior art, to prevent them from being patented.  I found this:
http://en.wikipedia.org/wiki/Trusted_timestamping
But I'm not really sure where to go from here.  Can anyone recommend an app to do this?  If it's relevant, I'm on a Mac running 10.7.  Most of the ideas require on the order of $5000 or more in living expenses and materials to explore over a couple of months, but they are not technically complicated, just abstract.  I'm hoping eventually to see a kind of github/kickstarter for inventors so they can get the small funds to tinker on their projects and then release them into the public domain.  Any ideas/suggestions there would be much appreciated.  Projects like the windbelt and electric multicopter come to mind.  There are so many relatively easy ideas that could move us into the 21st century but most of us are still trying to make rent each month...
Thanks! <comment><USER2> A number of CAs can supply certificates under Adobe's Certified Document Services scheme:

<http://www.adobe.com/security/partners_cds.html>

As far as I know these all include the use of a RFC 3161 compliant timestamping service:

<http://en.wikipedia.org/wiki/Trusted_timestamping>

I've used GlobalSign to obtain the relevant certificates and associated hardware (for personal use this is a small USB token):

[http://www.globalsign.com/document-security- compliance/adobe...](http://www.globalsign.com/document-security- compliance/adobe-cds/)

</comment><comment><USER3> The old way of doing this was to put it in a sealed envelope and mail it to yourself - with the postmark being the timestamp.

As for your ideas, there are several projects on kickstarter et. al. that do handle things like that. One of the more recent ones was the Global Village Construction kit.

Try it out, see if you can get funding.

</comment><comment><USER4> Just file a patent application for them, as you don't care about actually patenting them you won't need to shell out for patent lawyers, so you just need to pay a relatively small filing fee.

Plus it makes it much more likely that your patent will turn up in prior art searches.</comment>


Rolling Haiku Style At CPAP.com - <AUTHOR> http://grab.by/gf8E

<comment><USER2> hah That was fun to write. Didn't think it'd actually get posted here, but hey, what's life without a little whimsy?</comment>


Ask HN: Computer Science in Canada: Toronto or Vancouver? - <AUTHOR>

So, it's almost (finally) time for my graduation - less than a year. I've lived in Canada my whole life and want to continue living here a while more. I consider myself lucky having experienced life in Toronto and Vancouver in almost equal amounts. I've come to conclude that, for myself, either city would make a fine home, but what about work?
Which city (Toronto or Vancouver) would lend itself to: - Higher salaries - More start-up companies - Interesting jobs - Easier to get a job (with a BSc in Comp Sci) - More tech jobs available - Working for Big-Name companies - a larger IT/Tech community - IT/Tech events/conferences
If you have anything to add to the list that is not present, please feel free to do so.
Any constructive help is appreciate! Thanks for the replies in advance! <comment><USER2> Perhaps this is the time where attempting to match your current interests with where you think your interests will be post-graduation would help. Are you in high-school or just about to finish up your Bachelors?

Specifically, Toronto seems to have a greater variation in the number and, presumably, types of firms that would seek out Comp Sci graduates. As an example, if you had an inclination to work within Finance tech, then your best bet by far would be Toronto since all the major financial firms and banks are located primarily in Toronto.

Alternatively, if you're interested in game development, I hear that Vancouver seems to have strong presence, mainly due to the influence of EA's Vancouver (Burnaby) location, with a vibrant startup scene. I haven't heard of other types of firms with a strong demand for CS in Vancouver other than gaming and startups.

I can't comment on Waterloo nor Montreal, except that they both seem to be continually growing tech hubs. RIM and UofW are strong reasons for the talent draws in the Waterloo region, and the Montreal startup scene seems quite lively.

From a salary perspective, most people tend to agree that Vancouver firms pay lower than Toronto equivalents. I can't comment on startup salaries since they're so specific to the situation (startup stage, equity vs. salary compensation considerations).

On a more personal note, although I agree that either city would make a fine home, I find Toronto highway traffic a complete mess compared to the Vancouver bridge bottlenecks. Tech events and gatherings tend to be located within downtown Toronto. A younger person will have more fun living downtown or in a subway accessible location. If your job is in Mississauga (due to the cheaper commercial lease rates), then from personal experience I can attest the commute will significantly bring down your quality of life.

<comment><AUTHOR> Firstly, thank you for the great reply!

I'm graduating from U of T (should have clarified that). I've heard the same things about Toronto and Vancouver as you've mentioned, but it's good to have my sources confirmed. I'm not so adamant about being in the Financial Tech industry, so the gaming one in Vancouver would be more viable. However, salary would sway me to stay in Toronto.

I've been in those Vancouver bottlenecks, but not Toronto's traffic so it's good to hear some sort of comparison. Living in North York shouldn't be a problem in terms of a commute.

This is a great start to start weighing job options. Thanks!

</comment></comment><comment><USER3> What about Waterloo? We've got tons of tech companies, both big and small. It's also significantly less expensive to live here than Toronto or Vancouver.

<comment><AUTHOR> I've looked into some of Waterloo's tech companies. I'm not sure what sort of jobs they are, still, but if they have any entry-level (graduate-experience) jobs, I'll be sure to consider them. Good to know that there are other options with cheaper housing!

</comment></comment><comment><USER4> Why discount Montreal? They've got a great start up scene.

<comment><AUTHOR> I was in Montreal for this year's CUSEC and revisiting that city, I can only say that I fell in love with it. I'm not sure of their startups, but I saw a games company there (Eidos, I believe..).

I'll look into jobs there for sure - if not for a reason to eat in Montreal again. Yumm....

</comment></comment><comment><USER5> I'd go for Toronto or Waterloo.</comment>


CλaSH – From Haskell to Hardware - <AUTHOR> http://www.clash-lang.org/ <comment><USER2> Disclaimer: I haven't read through the details of the language yet.

> _The merits of using a functional language to describe hardware comes from > the fact that combinational circuits can be directly modeled as mathematical > functions and that functional languages lend themselves very well at > describing and (de-)composing mathematical functions._

Whenever I read something like this, I cannot really take the language or the language designer seriously. The complexity and difficulty of hardware design is not in the _combinational_ part, it's in the _sequential_ (i.e., state- carrying) part of the circuit [1]. One of the major drawbacks of Verilog, SystemVerilog, and VHDL, is that successive sequential statements have to be translated manually to state machines (at least for synthesizable code – simulation code does not suffer from this restriction) [2].

[1] Source: I'm an FPGA design engineer with a computer science background.

[2] There are of course languages with an improved design, but nearly all of them are research prototypes and unsuited for non-toy/example designs. The more innovative commercial products have hardly any marketshare, because electrical engineers seem to be extremely conservative [1].

<comment><USER3> I used to work in ASIC design and verification. I have to agree with you. I can't take any of this stuff seriously.

They are all toys aimed at newbies. They address problems that are no problem at all to a qualified engineer in the profession.

Combinatorial logic is not hard. I would argue sequential stuff isn't that hard either. It's all undergrad engineering stuff studied in the first year or two.

The design size of a modern ASIC is at a massive scale that makes the problems of whichever description language trivial. Even the cheapest stuff has quite a few modules: memory controllers, CPU, caches, power stuff, bus controllers, various io modules, debugging modules. Nowadays it's multiple cores. Even the sub modules are just wrappers around other cores sometimes.

The teams are large, usually in the dozens because the problems are non- trivial.

This clash stuff is like building a mailbox. Engineers in the profession are designing and verifying the equivalent of an apartment complex.

<comment><USER2> Thank you for this perspective from the top. Sure, when verifying the final ASIC design, the problems of the implementation language don't matter much anymore. _However_ , those IP cores have to be written by _someone_ , and they actually get to suffer the deficiencies of the HDL.

> _I would argue sequential stuff isn 't that hard either. It's all undergrad > engineering stuff studied in the first year or two._

So? That's like saying that _" writing software isn't that hard either. It's all undergrad comp science studied in the first year or two"_, which is obviously false. If your tools and languages suck, they'll slow you down and you'll produce more bugs – in software as in hardware.

I often get the impression, that many hardware engineers don't even realize how much their tools suck, because the lack the perspective on the outside world, specifically the software world, to see better ways of doing things.

<comment><USER4> I am a pretty junior ASIC engineer who has relatively more exposure to software world compared to many of my peers.

In my last project I did some IP integration work and the lack of decent development tools led to significant chores. I did make use of Emacs verilog- mode like GP mentioned and even wrote some small macros in elisp but overall experience is far from satisfactory. Not to even mention the usability of propriety EDA tools and flows. The software world just looks like heaven with so many awesome development tools available (VS, PyCharm, intelliJ, to name a few I've used). And I can tell the difference because I once managed to convert a C# GUI software into a console application mainly with the help of an IDE (Visual Studio), without first learning C#.

Sadly, I think ASIC (or maybe broader, hardware) industry has a pretty poor ecosystem in general. I'm not aware of good hardware focused community comparable to HN, no high quality active Q&A on sites like stackoverflow; even the HDL languages look inelegant and not well thought out. And you have a point, I'm not even sure how many of my colleagues realize that. I want to make some difference. But I'm not sure where to start...

<comment><USER2> > _I want to make some difference. But I 'm not sure where to start..._

1\. Take a promising language, improve it where necessary.

2\. Add excellent support for translation to VHDL and Verilog. The generated HDL code has to be readable, editable, and it has to reflect the structure of the original code more or less 1:1. You also need to support "inline VHDL/Verilog" (like inline assembly in software). Otherwise, your language doesn't integrate into the ecosystem of synthesis software, simulators, vendor-dependent Map/P&R, and existing IP cores, which makes it useless in the real world. This is the main reason why all innovative VHDL/Verilog replacements have failed so far. Without this feature, there's just no way your language is going to gain any significant market share.

<comment><USER5> 2\. I am curious to hear what you think about our solution of wrapping existing VHDL/Verilog in an external task in Cx? [http://cx- lang.org/documentation/tasks#external](http://cx- lang.org/documentation/tasks#external)

<comment><USER2> Very nicely done!

Is there a way to get in contact with you? I suppose you're either Nicolas or Matthieu?

<comment><USER5> Yep, I'm Matthieu! You can send me an email at matthieu.wipliez at synflow.com

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> There's been a few different proposals to use functional languages to write hardware: Chisel ([https://chisel.eecs.berkeley.edu/](https://chisel.eecs.berkeley.edu/)) and Bluespec ([http://www.bluespec.com/](http://www.bluespec.com/)) are two others. They haven't really taken off because the productivity bottleneck in hardware is not in design but verification and specifically sequential verification. Combinational verification is quote easy, because modern SAT solvers can prove almost all combinational properties you can throw at them.

The trouble comes in when you start dealing with complex state machines with non-obvious invariants. I don't think these functional languages can really help too much here because unlike C or C++ in the software world, there isn't unnecessary complexity introduced by a language, e.g. verification becoming harder due to aliasing. It's the properties themselves that are complex. Lots of progress is happening though: Aaron Bradley's PDR ([http://theory.stanford.edu/~arbrad/](http://theory.stanford.edu/~arbrad/)) and Arie Gurfinkel and Yakir Vizel's AVY ([http://arieg.bitbucket.org/avy/](http://arieg.bitbucket.org/avy/)) have made pretty major breakthroughs in proving a lot of complex sequential properties and these algorithms have made their way into industrial formal tools as well.

</comment><comment><USER7> Interesting idea. Very similar to Bluespec Verilog ([http://www.bluespec.com/high-level-synthesis- tools.html](http://www.bluespec.com/high-level-synthesis-tools.html)) which also builds on a foundation of Haskell to Verilog translation ([http://en.wikipedia.org/wiki/Bluespec,_Inc.](http://en.wikipedia.org/wiki/Bluespec,_Inc.)) Unlike CλaSH, BSV is non-free (CλaSH is using a BSD License) which is a major (and cool) difference.

Having said all that, I'm currently writing a lot of Verilog for a system design that I'm working on. I also learned to program Haskell at university, (although it's been a few years...), so this language would seem PERFECT for me. But it isn't...

Reading through the CλaSH documentation/tutorial I've found the examples are baffling. I have no idea what is being written in either Haskell or Verilog space. The examples seem to be focusing on the language aspects of the tool rather than how to express actual hardware in it.

It would help me greatly if the authors would go through something like this: [http://asic-world.com/examples/verilog/index.html](http://asic- world.com/examples/verilog/index.html) or this: [http://asic- world.com/examples/vhdl/](http://asic-world.com/examples/vhdl/) and write a side by side comparison of how I express these fundamental hardware concepts in this new language.

<comment><USER5> The way I see it, it's Register Transfer Level, just written differently. Instead of writing: @always(clock) counter <= counter + 1;

you write: counter = s where s = register 0 (s + 1)

per [http://hackage.haskell.org/package/clash- prelude-0.7.5/docs/...](http://hackage.haskell.org/package/clash- prelude-0.7.5/docs/CLaSH-Tutorial.html)

I agree, it is an interesting _idea_. I suspect that just having "Haskell" got the link a lot of upvotes :-) As stated on the "Why CλaSH", the advantage is obvious for combinational circuits. But it doesn't seem to help much for synchronous logic (which arguably represents the majority of hardware designs). You'll still be writing everything as "how to update register X in state S".

<comment><USER7> Helpful explanation. Thanks! Looking at this I have a very specific question, from a practical getting work done point of view, is this _better_ than what we have, or just _different_ to what we have. If the answer is "different" I don't mind, but it will hinder my adoption ;-) I guess this is why I want to see a side-by-side comparison of real hardware constructs. Things I use regularly. It would aid greatly in understanding the (potential) benefit of expressing things these ways.

<comment><USER5> Hard to say, it depends on what you consider better. It certainly is more concise than the equivalent Verilog (just like Haskell is more concise than pretty much any language I know). This seems especially true when you want to describe repetitive structures (such as their FIR filter).

CλaSH also has a much better type system than Verilog (again, thanks to Haskell), but if you wanted a good type system when describing hardware, you might as well just switch to VHDL ^^

My concern is with the description of state machines. You need to specify if you want a Mealy or a Moore machine, something that is usually implicit. And you're still describing the transfer function between states; CλaSH does not seem to allow you to describe your program in a structured way (such as loop until x becomes true, wait for 3 cycles, read z, while z > 0 decrement z, etc.)

</comment></comment></comment></comment><comment><USER8> This is very interesting. I have always felt that having a language that has immutable constructs translates very well into a hardware description language. This is because most of the hardware modules are immutable, except for state machines, which can be modelled using state monads(or something similar).

Considering the hardware tooling right now, I would love to see a language with more abstractions than verilog or vhdl. I would love to see programming languages, that just don't compile to system verilog / VHDL, but can directly move to synthesizing step. I have worked with Bluespec and I don't see that as the successor.

I would say, a language like haskell(or a derivative) can map to a hardware really well, and this is a very good attempt. Please pursue it / turn it into a product, so that hacking on hardware(a FPGA) is much more easier and beautiful.

</comment><comment><USER9> the CλaSH vs Lava page was interesting: [http://hackage.haskell.org/package/clash- prelude-0.7.5/docs/...](http://hackage.haskell.org/package/clash- prelude-0.7.5/docs/CLaSH-Tutorial.html)

</comment><comment><USER10> I tried this out briefly while working on a VHDL project some time ago. I absolutely love how quick it is to run and test your code, compared to the toolings for VHDL. Also, Haskell's terse syntax is very much a plus! :)

</comment><comment> d-equivalence When I was writing the chips from nand2tetris in HDL I noticed how cleanly they could be expressed with function composition in SML. I dismissed the ideas as a bit weird, if cool, but after a few weeks I came across HardCaml [http://www.ujamjar.com/hardcaml/](http://www.ujamjar.com/hardcaml/) and some references to HML (Hardware ML). Unfortunately only the thesis survives and not any actual code, but still.

The moral of the story is to take your weird ideas more seriously I guess ;-)

</comment><comment><USER11> I don't know a first thing about hardware design, so it's a good opportunity to ask a question.

So say it would be something actually useful and after some tinkering I'm actually generating nice Verilog specifications. Can I apply it somehow if I'm not working in Intel or something? What can I do with it?

<comment><USER12> > I'm actually generating nice Verilog specifications. Can I apply it somehow > if I'm not working in Intel or something? What can I do with it?

Throw it into an FPGA

<comment><USER11> And it would be significantly faster than if I would concentrate on optimizing the code for, say, executing it on GPU?

<comment><USER13> Perhaps. Perhaps not. If you have an algorithm that is better implemented in hardware, you might well see better performance executing it on a GPU (for example, if you want to mine bitcoins).

Really, FPGAs are _meant_ for prototyping hardware; you synthesize your ASIC onto the FPGA and check it for functionality.

Of course, there's a reason you're making that ASIC.

<comment><USER12> Or you don't do an ASIC and ship the FPGA. That's common as well (for the big manufacturers it's cheaper to do an ASIC, for the not so big, it's more common to sell the FPGA)

</comment></comment></comment></comment></comment><comment><USER14> Newbie here. From the page seems that CλaSH can be used to other tasks apart from a hardware modeller, it's that true?

<comment><USER15> What kinds of other tasks do you mean? Clash's surface language is Haskell, which is a general purpose programming language.

</comment></comment><comment><USER16> I've used CLaSH over most of the pass year to do all my Verilog assignments (CS major doing EE electives), and also contributed a bit to the project, so figure I'd offer some insight.

For all you saying "but sequential is the hard part". Yes functional programming is most clearly a smash-hit with combinatorial circuits, but CLaSH shines with sequential circuits too. Basically, time-varying nets are represented as infinite streams where the nth element is the value at the nth cycle. Registers are basically `cons`, they just "delay" the stream by one cycle, tacking on the initial value in front. To make complex sequential code you just "tie the knot" around the streams with `letrec`s -- which actually corresponds to exactly what the feedback loop looks like on the schematic. [Anyone that's done FRP should recognize this ideom.] In this way CLaSH is both more high-level and more low level than Verilog/VHDL: clocks nets are derived automatically, but feed back loops are explicit.

Now if you are an electrical engineer, subsisting one tedious task (routing clocks) for another (programming without "blocking assignment") might seem like no net gain. But us functional programmers are fluent at working with such fix-points, and abstracting both what we tie together an the knot-tying itself. The Moore and Mealy combinatorial are the tip of the iceberg -- examples that we hope will be more accessible to electrical engineers unfamiliar with functional programming.

For all you saying that "the hard part isn't working with the HDL at all, but lower level concerns like timing, layout, etc", I have two things.

First you are acting like HDL writing is not on the "critical path" of your development process, and thus of no concern. Well that's not just true--you can't have one engineer do HDL writing, one do layout, and one engineer do testing completely independently because there are some basic data dependencies here that linearized the development workflow. It may not be the component with the "most delay" but it's still on that critical path, and thus improving it will yield at least some speedup to some extent. Automatic layout and timing analysis is great too, but unless you have a massive amount of computing power at your disposal, AFIAK you can't get very far, so improving the HDL side of things might be the /best/ you can do.

Second, there is the development cost of finding all your bugs with low-level tools. Yes timing analysis is essential, but it's not great in diagnosing the underlying problem. If you have lots of code that, well, isn't very aesthetically pleasing, and you do all your debugging on FPGA or with timing analysis, I suppose just about all bugs look like timing issues. With CLaSH:

\- You have far less code, and it's more high-level, so just reading looking for errors it is more productive. \- You can try out your code on the repl, seeing providing a stream of inputs and getting a stream of output. High level state machine errors (do you really nail this the first time with verilog?) are easily caught this way. \- Because you have more opportunities to modularize your code, you have more opportunities to test components in isolation. Unit tests vs. System tests--y'all know the deal. The former is no panacea, but obviously it makes complete code/path coverage way more tractable computationally. \- QuickCheck. I generate programs, run my single-cycle and pipeline processor for n cycles, see if they both halted and compare register/mem stage, otherwise throw out the test. I /suppose/ you could do this with C-augmented testbenches, but it would be way, way, way more code and effort. QuichCheck worked so well that I never wrote a test bench. \- EVENTUALLY, with idris or [faking it with] dependent Haskell prove your circuit correct up to the synchronous model CLaSH is built around.

In practice I can say I honestly wrote and debugged programs all from GHCi (the Haskell REPL, so very much in software land), and saw them work first time on the FPGA. Where this didn't happen was usually do to a black boxes, like megfunctions and other components on the dev board. Obviously my Haskell testing is of no use if I model them wrong in CLaSH.

Finally, it would be dishonest and misleading to not mention CLaSH's downsides. CLaSH is designed assuming your circuit is totally synchronous (or purely combinatorial, but that's the trivial case). I don't know often this comes up in the real world, but in interfacing with the components on the dead board, I often had to do things that violated rigidly synchronous circuit design --- inverting my clock to get a second 180-degree-off clock domain, asynchronous communication with SRAM. [CLaSH supports multiple clock domains, but only knows about their relative frequency, not phase.] You can often still describe these circuit in CLaSH, but because it violates its synchronous model, it won't understand them and neither will your Haskell-land testing infrastructure. Basically you loose the benefits that made CLaSH great in the first place. Fundamentally, I think true fixing these cases means designing a lower-level "asynchronous CLaSH" that both normal CLaSH and these cases can elaborate to. Trying to tack them on as special cases to CLaSH and it's synchronous modle won't fly.

But all is not lost, if you can contain the model-violation to one bit of code and give it kosher synchronous interface, you are all good. Write some Haskell to simulate what it does (need not be even in the subset CLaSH can understand), and make a Verilog/VHDL black box. CLaSH doesn't help you with that module, but that module doesn't pollute the rest of your program either. Most real-world designs are by and large synchronous, unless the world has been lying to me. So the quarantined modules would never form a significant part of your program.

That about wraps it up, ...hope somebody's still reading this thread after writing all that.

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

<comment><USER16> 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...](https://hackage.haskell.org/package/clash- prelude/docs/CLaSH-Signal-Explicit.html#g:4)

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...](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)

Note that the testBench code works in Haskell too.

<comment><USER3> 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.

<comment><USER16> 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.

\</comment></comment></comment></comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>

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/47...](http://www.researchgate.net/profile/Jan_Kuper/publication/47936996_Comparing_CaSH_and_VHDL_by_implementing_a_dataflow_processor/links/02e7e520c06378cdbd000000.pdf?origin=publication_detail)

<comment><USER3> Verification IP is reusable code created by verification engineers. E.g. Say the designers are developing a networking module. The verification engineers would build the verification IP to generate the network packets. They also build the monitors to check the network protocols. For any design under verification, there is a corresponding amount of verification providing stimulus and checking.

Check out: [https://verificationacademy.com/verification-methodology- ref...](https://verificationacademy.com/verification-methodology- reference/uvm/docs_1.1c/html/files2/intro-txt.html)

The reason I bring this up is: verification is the hard part of the HW workflow. The other similarly tough part is synthesis. Every single project I have been in, verification and synthesis are the toughest tasks that consumes the most team effort. Not design. When we plan projects, it all revolves around the verification task.

For every bus, every module and at various stages of SoC integration, we are writing verification code using System Verilog.

If you want to improve our tools, I would look at the verification/simulation or the synthesis side.</comment></comment>


Ask HN: How do you explain to non-technical people that bugs happen in software? - <AUTHOR> I work in a software agency, and we have some clients that don't understand that bugs tend to happen most of the time. Also that those bugs will lengthen the estimated time of the project. Any useful analogies that some of you use to explain all of this sort of stuff? <comment><USER2> I generally try to make it relatable to them. I have yet to find any other industry that doesn't have similarities where things go wrong no matter how well the plan was at the start. The way I found was best is to ask a lot of questions up front about their industry and typical delays, "issues that comes up etc before anything has even happened. Then when the nearly inevitable delay and inevitable bug comes up it is easier to explain it to them.

In the event you didn't do this up front and don't know their industry well enough, you can use common analogies of building a house, and the delays and cost overruns that are so typical there. Many times caused by clients wanting changes or items which were not spec'ed correctly up front etc.

In the end I have always found it is best to not get defensive, and not be dismissal like this is just normal, but to explain that there are a lot of challenges to engineering anything, whether it is a website or a PCB. Also know your audience. Some people want all the details and that makes them feel better that they understand. Others just want the new date and a reason why it is more solid than the last, or want to know you are handling the bug and it'll be complete by X. Don't try to explain details to the person who just wants to know when it will be fixed, and don't try to dismiss the person who wants to try and understand the details.

One other example I have used for people that are less technical, I will ask them if they ever wrote a multipage term paper or something to the sort in school (everyone has usually). And I'll ask, did you ever make a grammar mistake? How about a spelling error? Ok, now imagine that paper isn't 10 pages long (~600 lines) but instead 100 or 1000 pages long, what do you think the chances are we will find some mistakes when we start proof reading it? What about after we have proof read it 10 times? Do you think there still might be some issues 5 days later when someone else has read it? Usually this helps people.

</comment><comment><USER3> Imagine balancing a checkbook with 10,000 transactions where if you're off by a penny the account shuts down and becomes inaccessible.

</comment><comment><USER4> Perhaps making a sponge cake?

You can know all the ingredients and know how long each step takes. You may have made it successfully before too. However if the yeast is bad then the sponge won't rise, if the eggs are not fresh or not at room temperature then you will have more problems... you need to go back and make the sponge again.

</comment><comment><USER5> If you buy a brand new house, you do a walk-through and make a list of problems you want the builder to fix.

These are bugs.

No one would skip this step when buying a new house because there are always bugs.

</comment><comment><USER6> You could say "Our product reacted in a way that wasn't intended and we are currently working on a solution."

<comment><USER7> I like it. It's plain and simple.

</comment></comment><comment><USER8> > bugs tend to happen most of the time.

They do? Software not working most of the time is indicative of poor quality software and untested requirements.

Yes, poor quality software has lots of bugs. Yes, many companies are selling poor quality software. But, high quality software does not have any bugs for the required use cases.

"Bugs tend to happen most of the time" sounds like someone is not taking responsibility.

<comment><USER9> "They do?" sounds like someone doesn't have a lot of experience. Bugs do happen most of the time, even in high quality software (whatever that is). Sometimes they're the result of sloppy code, other times, they're the result of sloppy requirements and other times, they're the result of poor communication.

<comment><USER8> In my experience, bugs do not happen "most of the time" (OPs words). I've been a software engineer for 12 years. High quality software is software that works, for the required use cases and devices.

> ... _most of the time_

> ... _for the required use cases._</comment></comment></comment>


Combustion-derived nanoparticles in Alzheimer disease development: study - <AUTHOR> https://medicalxpress.com/news/2017-06-culprit-hidden-plain-sight-alzheimer.html <comment><USER2> I guess fine Particulate Matter (PM) is the lead of the 21st century. Hopefully findings like these (and those linking it to cardiovascular issues) will prompt legislators to action.

<comment><USER3> Fine particulate matter was the lede of last century too. Asbestos (mesothelioma), talcum powder (ovarian cancer), titanium dioxide (it's in everything), plastic microbeads (voluntarily discontinued), 9/11 cleanup crew issues, Doritos flavor dust (I saw an article on this somewhere...)

How do we solve particulate getting in your brain though? Nanorobots for removal?

<comment><USER4> I think Tharkun mean "lead" as in leaded gasoline and lead paint.

<comment><USER3> Good one, thanks. In that case I would expand lead to be heavy metals generally (lead, mercury, cadmium, arsenic etc)

<comment><USER2> Ah yes, sorry about the confusion. I was indeed talking about lead (Pb), or rather tetramethyllead as it was added to gasoline as an anti-knocking agent last century. It's something that was suspected to be bad early on, but the scale of it wasn't realized until much later. Of course, political nonsense and corruption came into play as well.

Just like now.

</comment></comment></comment></comment></comment><comment><USER5> Magnetic air filters for the home, anyone? Its an untouched market!

Not to mention magnetic filters for motorcyclists. Asia is full of motorcyclists who use dust masks. Adding a "magnetic filter", even one barely effective, might be very popular in Hanoi and Saigon, for example:

[https://www.google.com/search?q=motorcyclists+in+saigon+wear...](https://www.google.com/search?q=motorcyclists+in+saigon+wearing+masks&client=opera&hs=fJq&source=lnms&tbm=isch&sa=X&ved=0ahUKEwiDt_TFwbbUAhUKw4MKHSm2Dj0Q_AUICigB&biw=1105&bih=845)

Finally, an application for old disk drive magnets!8-)): grind them up into coarse domain-sized grains at low temperature (so they don't lose their magnetism) and then toss them into the paper/fiber pulp mixture used to make masks. You should get a mask that filters the usual particles and also captures iron nanoparticles.

Add a few billboards on major highways depicting nursing-home residents with Alzheimers' disease and saying "Don't end up like this!" and those masks will be flying off the shelves. Profit!

<comment><USER6> This sounds like a pretty brilliant idea to me, why isn't it already on the market? The article specifically calls the problematic particles "airborne iron-rich strongly magnetic combustion-derived nanoparticles (CDNPs)".

<comment><USER5> It _has_ been discussed before: I just found a 2007 paper about dust problems in lunar living environments; the suggested solution is a magnetic air filter. Their solution is different of course (I was simply brainstorming about the powdered domains solution - there are many ways to magnetically filter particles from the air):

"DUST MITIGATION: LUNAR AIR FILTRATION WITH A PERMANENT-MAGNET SYSTEM " [http://www.lpi.usra.edu/meetings/lpsc2007/pdf/1654.pdf](http://www.lpi.usra.edu/meetings/lpsc2007/pdf/1654.pdf)

There are probably many more such ideas published.

</comment></comment></comment><comment><USER7> "combustion-derived nanoparticles" they mean car exhaust right? airborne pollutants from burning things. seems like just another reason to get rid of fire based energy.

<comment> semi-extrinsic FWIW, particulate matter comes not just from exhaust, but also from road wear etc. that EVs will actually be worse at (since they're heavier).

I don't recall the split off-hand, but here's a paper that should have some numbers:

[http://www.sciencedirect.com/science/article/pii/S1352231013...](http://www.sciencedirect.com/science/article/pii/S1352231013002732)

<comment><USER8> I'm not sure if it has been looked into yet, but once EVs are abundant it would make sense to look into ways of reducing pollution from road wear. Right now it's not worth it as much, since pollution from the cars themselves dominate. But once road wear is the dominant source it'll make sense to look into it.

Automated cleaning trucks which sweep the road for dust every day maybe? New materials for roads and tyres?

<comment><USER2> New materials might be tricky. Roads are very abundant, and in some places of the world they're a convenient way of disposing of the leftovers of incinerated waste.

</comment></comment></comment></comment><comment><USER9> "A Look Into the Dramatic Rise in Alzheimer's Cases" [http://www.huffingtonpost.com/eric-j- hall/alzheimers_b_51789...](http://www.huffingtonpost.com/eric-j- hall/alzheimers_b_5178982.html)

I'm guessing this is a time bomb that will be with us for some time.

</comment><comment><USER10> Well then I guess switching from combustion engines to electric engines will reduce this contamination. But how much new stuff that uses nano particles for all sorts of things is going to mess up our bodies and cause other health problems they will be dealing in the next century if we're still around.

</comment><comment><USER11> Oddly enough this sounds like Stephen King's The Running Man ...</comment>


How Exercise Fuels the Brain - <AUTHOR> http://well.blogs.nytimes.com/2012/02/22/how-exercise-fuels-the-brain/?gwh=E719F4F4FBE1F513EB0D1E0E9ACFD189

<comment><USER2> I expected this to be a fluff piece about exercise and learning, but it was in fact rather interesting.

It should be noted that while increased "glycogen supercompensation" in the brain correlates with the much-hyped exercise-induced-cognition-enhancement (aka running makes you smarter/healthier/happier) the author's don't provide any behavioral or cognitive tests. They acknowledge this, and since it wasn't part of their study they just offer the correlation as an interesting hypothesis.

I imagine they'll be testing cognition/behavior in their next paper.

The articles they are referencing is:

<http://www.ncbi.nlm.nih.gov/pubmed/21521757>

<http://www.ncbi.nlm.nih.gov/pubmed/22063629>

</comment><comment><USER3> Great content. Scientific, only presents the facts, and doesn't take the typical "THIS CHANGES EVERYTHING" sensationalist approach. Good on the author and the NYT for reporting actual science.

<comment><USER4> _And_ they link to the source of the article. I feel like ticking this day in my calendar to mark a good day of journalism.

<comment><USER5> Indeed.

</comment></comment></comment><comment><USER6> I wonder if physical activity correlates with education results. For example, in Finland kids typically walk or bicycle to school and are also actively running or playing on 15 minute breaks every hour.

<comment><USER7> Research suggests that it does. The book "Spark" by John Ratey goes into this in depth. [http://www.amazon.com/Spark-Revolutionary-Science- Exercise-B...](http://www.amazon.com/Spark-Revolutionary-Science-Exercise- Brain/dp/0316113506/)

<comment><USER8> I have to second the "Spark" recommendation. It presents the very compelling research behind exercise's cognitive and mood benefits. I've read many of the articles and books on this topic and Spark still included new information for me.

After reading it I decided to finally get on a religious exercise schedule and I've been on it for two months. The improvements to my will-power, focus, and mood have been tremendous.

As a side note: one thing that has helped me keep up the 5 to 6 exercise sessions per week is reminding myself that I'm only exercising for cognitive and mood benefits. This helps me personally not get distracted by other factors like fat-loss, improving running times, etc. If I added other non- brain goals, then it'd be easy to get bummed out and discouraged if I didn't achieve them, so I keep my goals purely brain focused. If those other benefits happen as a result of the exercise, then great, but they are not why I'm doing it.

</comment></comment></comment><comment><USER9> Here's a few key take-aways that I hope I'm not extrapolating.

1\. Exercise without the proper "carbo-loading" can eliminate the cognitive benefits that astrocytes provide in restoring glycogen to neurons. 2\. Exercising every now and then versus continuously will not provide these benefits. Intermittent exercise may just provide temporary (up to 24 hrs) cognitive benefits whereas continuous exercise may allow it to last longer (more than 24 hrs).

tl;dr Article should be renamed to: "Continuous Exercise with Proper Post- Workout Nutrition (Carbs) Fuels the Brain"

<comment><USER10> Excuse my ignorance, but isn't beer full of carbs? =)

<comment><USER11> 1 pint of beer == 1 slice of bread (ish, in terms of carb content)

But, a quick experiment will show you that

6 pints of beer /= 6 slices of bread

</comment></comment></comment><comment><USER12> I started exercising regularly last week and I've noticed that my productivity has soared! Until I read this article I wasn't entirely sure if the two were correlated, but now I'm thinking there is something to it. My exercise time is in the early morning, and it's been a great way to start the day.

</comment><comment><USER13> I wonder what types of exercise trigger this effect and to what degree. Off the top of my head (going by their descriptions) team sports would be ideal not just for the exercise but the constant situational analysis, team work, running plays etc would increase the workload on the brain.

</comment><comment><USER14> I always get a kick out of articles whereby they basically say 'hey, excercising is good for you!', as though that were some kind of new discovery :) This is a good article, and as others have mentioned it actually links to scientific study, which is a rarity for mainstream press. On the other hand does anyone here think that getting regular excercise WOULDN'T be better all around, in a multitude of ways, than say sitting on your ass all day?

<comment><USER15> Invariably on exercise-related articles there will be a comment saying, basically, "Congratulations, science, for proving the obvious..."

The proper response is always the same: even what seems intuitively obvious needs continual verification through the scientific method, both to understand the underlying physical mechanisms that drive a phenomenon, and to detect situations where our intuition is wrong.

</comment></comment><comment><USER16> So the hypothesis is that the reason cardio exercise every other day makes you smarter is because the astrocytes next to your neurons in your frontal cortex and hippocampus become 60% more capable of meeting needs to fuel your neurons with glycogen during periods of glycogen shortage, increasing the brains ability to keep glycogen levels at optimal levels at all times during the day.

I would like to see a study done seeing how 5 hour powers, caffeine, sugary treats, no-doz and other performance altering drugs affect this astrocyte supercompensation process.</comment>


Hurricane-Killing, Space-Based Power Plant - <AUTHOR> http://blog.wired.com/wiredscience/2009/04/weathermod.html

<comment><USER2> Hurricanes/Cyclones/Typhoons (all the same thing, just different oceans and hemispheres) are an important way to release heat energy built up in the ocean. That's why they happen at the end of summer.

I can't see how introducing more heat into the system from a _giant frickin' space "laser beam"_ could work out well in any way.

</comment><comment><USER3> When will people learn?!? Look, two things you need to know about Hurricanes:

1\. Hurricane's are stronger than you can imagine! Imagine the biggest force you can? Was it a nuclear bomb? Funny, because a Category 5 Hurricane is equivalent to setting off one 10-megaton Nuke every 20 minutes! (See subject C5c -- <http://www.aoml.noaa.gov/hrd/tcfaq/TCFAQ_C.txt>)

2\. Hurricanes, for all the destruction they can cause, are a "Good Thing". Just like occasional burns in forests are a natural way of clearing out brush, and preventing them only leads to bigger fires, hurricanes redistribute heat energy from the equator to the poles, and preventing them would only lead to bigger hurricanes!

</comment><comment><USER4> Notice NOAA's statement... When we have enough energy to fly at nearly the speed of light, we might be able to control hurricanes.

Given that the NOAA people are probably smart, they probably realize how difficult this is.</comment>


"Maybe" is one option too many - <AUTHOR> http://www.zeldman.com/2007/06/20/remove-maybe-from-invitation-systems/ <comment><USER2> For a really excellent, far more comprehensive and much better articulated series of articles pertaining to ratings/rankings, check out www.lifewithalacrity.com

Some of the articles include: Using 5 Star Rating Systems, Experimenting with Ratings, Systems for Collective Choice, Rating Systems, Competitive Ranking Systems

The ratings users choose are certainly influenced by the presentation of the rating opportunity. The result of forcing "Come on guys rate everything!" down users' throats is that if people really dont have an opinion or feel strongly, most likely they will indicate neutrality. If users have more of a choice about contributing a rating then only the users who have a strong opinion will take the time/effort to complete a rating and so you will end up with a bimodal distribution.

The good/bad or star ratings are always useless to other users without the accompanying explanation of the review.

</comment><comment><USER3> _Let users choose from five stars, and they nearly always pick three_

Amazon has the problem of bimodal distributions for their ratings...nearly every user either votes one star (and bitches, "If I could choose zero, I would") or five. They've actually started sending emails to people requesting reviews to fix this problem (to get the silent majority to vote.)

<comment><USER4> I think the "liked it"/"hated it" options are basically enough all the time, at least in aggregate. RottenTomatoes.com seems to end up with good ratings despite reducing the answer space to green or red tomatoes.</comment></comment>


Minecraft Physics - <AUTHOR> http://www.wired.com/wiredscience/2012/02/minecraft-physics/ <comment><USER2> 'Unfortunately, this video is not available in Germany because it may contain music for which GEMA has not granted the respective music rights.' :(

<comment><USER3> This seems like an error; I'm pretty sure that song is long out of copyright. (GMEA can claim copyright on a particular performance of that work, but how does it know?)

Anyway, the transcript is the only important part; the sound is a computerized British voice reading the transcript with some classical music in the background.

<comment><USER4> Unfortunately, in Germany GEMA enjoys the privilege of inverted burden of proof. Look for `GEMA-Vermutung' for details.

</comment></comment></comment><comment><USER5> There's a couple of discussions on Reddit related to this particular video which offer some interesting criticism:

[http://www.reddit.com/r/Minecraft/comments/nrxme/minecraft_g...](http://www.reddit.com/r/Minecraft/comments/nrxme/minecraft_gravitational_analysis/)

[http://www.reddit.com/r/Minecraft/comments/p7lyz/minecraft_p...](http://www.reddit.com/r/Minecraft/comments/p7lyz/minecraft_physics/)

</comment><comment><USER6> How do they make the jump from 43 blocks to 43 meters? Are they assuming that each block is exactly one meter?

Also why did the video randomly go blurry at times?

<comment><USER7> Yes, one block is considered to be 1 cubic meter. [http://notch.tumblr.com/post/443693773/the-world-is- bigger-n...](http://notch.tumblr.com/post/443693773/the-world-is-bigger-now)

</comment></comment><comment><USER8> Another fun question would be to figure out what the terminal velocity is. It's reached pretty quickly when you jump off of things in Minecraft.

</comment><comment><AUTHOR> I know it is often the topic of SIGGRAPH demos, but I always get distracted now when game or demo physics don't go the extra mile in calculating all of the factors, or having realistic drag (and things like that)...

<comment><USER9> What would be the advantage of highly realistic physics though? In some cases it would improve gameplay (I remember the Newtonian physics in the Independence War games resulted in relatively novel gameplay) but in a lot of cases I don't think it would. Minecraft especially is kind of abstract, and it already struggles a bit with performance on some larger multiplayer games. Super realistic physics would just make this worse and not add that much to the gameplay, IMHO.

<comment><AUTHOR> Well, yes I can see in games it being just eye candy maybe, but even in incredibly flashy renderings (like heck even Target commercials) there's just sort of a basic Verlet integration of speed and acceleration or deceleration but not many things like air drag, friction on the surfaces, little "oops" that happen with uneven surfaces and random errors in trajectories, etc... I have seen SIGGRAPH white papers that contain a lot of these sorts of things and more as a group, and well, lets hope those eventually get read and used. The current state of the art reminds me of when I first learned Photoshop and I couldn't stand any magazine covers I saw (actually I guess I still can't heheheh)

<comment><USER9> Target commercials aren't really a fair comparison to Minecraft. One is the work of a team backed by large company and gets rendered once on powerful hardware (I think... I don't know what you're specifically referring to but I assume it's some computer animated spot) and the other was largely the work of one programmer and has to run on cheap PCs and Macbooks (sure it doesn't _have to_ but I would argue that's part of Minecraft's success: you don't need a gaming rig to play it, as you do to play something like Skyrim).

I definitely understand where you're coming from but keep in mind that you likely have a much deeper understanding of physics than most game players (and likely most game devs).

</comment></comment></comment></comment><comment><USER10> >Similar to Angry Birds, this is a great world to explore physics.

Comparing Angry Birds (a physics-based game) to Minecraft (a game with... gravity) is a bit of a stretch.

</comment><comment><USER11> Unfortunately GEMA blocks me from seeing that video.

</comment><comment><USER12> Anyone done this for other popular games? could be interesting as well!

<comment><USER13> There's the Sonic Physics Guide (<http://info.sonicretro.org/Sonic_Physics_Guide>), though that's more about implementing the physics of the original Sonic games in code, rather than explaining real-world physics through playing Sonic games.

<comment><USER12> Fascinating, thanks! Also useful in general for me!</comment></comment></comment>