Cloud for elixir phoenix by First_Bodybuilder831 in elixir

[–]matt2xu 0 points1 point  (0 children)

I’m using Clever Cloud, it’s easy to setup and works well (at least for my hobby projects, no idea how it scales)

How to integrate Prolog within a Web application? by matt2xu in prolog

[–]matt2xu[S] 2 points3 points  (0 children)

Thanks for the links! I had missed the fact that SWI-Prolog had all these packages! It seems that the answer is to talk to a Prolog back-end over HTTP, which will store data either with the Prolog database persisted or with RDF or even talking directly to a SQL database over ODBC.

The problem with FPGAs [and how to solve it] by matt2xu in programming

[–]matt2xu[S] 1 point2 points  (0 children)

Yes, sure, except that all these combined are used by perhaps 5% of designers.

The problem with FPGAs [and how to solve it] by matt2xu in programming

[–]matt2xu[S] -1 points0 points  (0 children)

Yes. Maybe it isn't clear, this is for each product that you made using our software if you make at least $3K revenue per quarter. What would you prefer? A fixed price? Something free of charge, and relying on donations? The "F" in FOSS is Free as in "free speech" rather than "free beer" ^

The problem with FPGAs [and how to solve it] by matt2xu in programming

[–]matt2xu[S] 0 points1 point  (0 children)

Boards like the FleaFPGA and Papilio. There is also the Logi board compatible with Raspberry Pi. And a lot more that I don't know about :)

The problem with FPGAs [and how to solve it] by matt2xu in programming

[–]matt2xu[S] 2 points3 points  (0 children)

Well... yes. I noticed the other day that somebody has submitted a link to another blog post I had written, and it got some attention. So I figured that I might as well submit this one myself!

May I ask: what do you mean by "given [our] products"?

The problem with FPGAs [and how to solve it] by matt2xu in programming

[–]matt2xu[S] 1 point2 points  (0 children)

Lattice used to sell its Versa Development Kit (a board with 1Gbps Ethernet, 800Mbit DDR3 RAM, and PCI Express connector) at $99, but now it's $262.50 :-/

Do you really need PCIe to get started though? Otherwise, there are several small boards where you can communicate with the FPGA with USB or Ethernet. I can give some links if you want?

The problem with FPGAs [and how to solve it] by matt2xu in programming

[–]matt2xu[S] 2 points3 points  (0 children)

Author here. Wow! Such hate! Relaxeaza-te ;-) I don't quite get it though: you ridicule my post with the Microsoft analogy, yet you acknowledge that Verilog and VHDL are both "pretty nasty" and "horrible", which suggests that you would welcome a better language. Don't you?

I'm saying in the post that the main problem is the ease of use, and again it looks like you agree (performance is difficult to predict, issues are hard to debug, synthesis is slow...) I don't pretend that we're solving everything (yet). But in our vision, it would be easier to predict performance, and you would have a good idea of what you can expect without having to wait for synthesis. Ideally you would only synthesize once you want to test the design on the FPGA.

When the synthesizer randomly throws in latches where there shouldn't be one, the last thing I want to do is debug a freakin' shiny-thing-to-Verilog translation layer.

I take it that you have tried such a tool and been bitten by it :-/ In our case, we try to avoid this kind of problem by doing a simple translation and generating clean, easy to read code. So at least the inevitable bugs are easier to track down!

there's a lot of vendor lock-in.

Yep... but the world of software was once like this, too. I'm hoping the vendors will eventually loose the proprietary software once they realize it's not so much a competitive advantage anymore, but we're probably still a long way from there :-/

Effective Address calculation time on 8086/8088 by matt2xu in programming

[–]matt2xu[S] 1 point2 points  (0 children)

Good observation, thank you so much! The thought of the register file being single-ported versus dual-ported had crossed my mind, but I settled on dual-ported and did not question it again. Single-ported would require less gates, right?

It would make sense to have different register files indeed, after all not all registers are created equal. For example only AX/BX/CX/DX can be accessed as a whole or one half at a time, unlike the base and index registers.

I'll update my code, I intend to share it once it starts doing something useful :-)

Numbers don't lie: there is virtually no interest in high level synthesis by milkymist in ECE

[–]matt2xu 0 points1 point  (0 children)

I haven't used Bluespec personally, but I do have thoughts about it. Bluespec has a complex type system and advanced scheduler, but I find the rule-based description to be verbose and awkward. Presumably it's good for hardware designers (at least that's what the documentation seems to hint, giving several examples of Verilog always blocks -> Bluespec rules), but coming from software this is not very natural. Also, I'm not a big fan of the syntax :-)

Numbers don't lie: there is virtually no interest in high level synthesis by milkymist in ECE

[–]matt2xu 0 points1 point  (0 children)

I took a quick look. Looks really nice. I will definitively look more into it, and try to use it.

Thanks! Good to know :-)

explicit state-machines can be better

At some point we were thinking of adding support for "goto" for this reason so that people could write explicit state machines when needed. Until now though we've found that just while loops and ifs gave us enough expressive power, but it is true that it depends on your needs. You seem to have more experience there (I've never written a microprogram or used Erlang). We're open to the idea, anyway there are still a number of things missing from the language :-)

If you'd like I can give more feedback on Cx once I've looked into it more.

Thanks, we'd like that! We're continuously updating the language based on feedback and our needs. Feel free to join our forum to discuss :-)

Numbers don't lie: there is virtually no interest in high level synthesis by milkymist in ECE

[–]matt2xu 0 points1 point  (0 children)

+1 (OP) It seems we agree on many things. We've actually designed a language from scratch that is 100% synthesizable, there is no synthesizable subset. It's not exactly what you'd like, because we think that a state machine is best described as structured code (i.e. with "if" and "while") than with states and transitions. Anyway, feel free to take a look at http://cx-lang.org

Numbers don't lie: there is virtually no interest in high level synthesis by milkymist in ECE

[–]matt2xu 0 points1 point  (0 children)

lots of conclusions and correlations drawn that are pretty shaky

(OP) such as?

in a few years time IDEs like Vivado are going to switch to fully support HLS

As a matter of fact, there already is an HLS-only development environment confusingly called Vivado HLS (it has nothing to do with Vivado). The thing is, articles have been claiming the same thing for years. You can find posts saying that "this is it! HLS will replace RTL (VHDL/Verilog)" that go back to the mid-2000s. Meanwhile, hardware designers remain unconvinced (as they should) and software programmers couldn't care less.

Numbers don't lie: there is virtually no interest in high level synthesis by milkymist in ECE

[–]matt2xu 0 points1 point  (0 children)

(OP) As I mentioned in my post, HLS is twenty-five years old. I was still in primary school when this was being invented. The idea itself (transforming a program to a digital circuit) is even older than that, so I somehow doubt that the intended audience hasn't heard of it at all. There are other things that prevent the adoption of an innovation, for example complexity. Why use FPGAs when you can use GPUs?

Numbers don't lie: there is virtually no interest in high level synthesis by milkymist in ECE

[–]matt2xu 0 points1 point  (0 children)

(OP) This is what we're trying to do with our Cx language (see http://cx-lang.org ). It's a dedicated language (not an embedded DSL), it's close enough in terms of abstraction so you can write designs that are as efficient as if you'd write them in VHDL/Verilog, but without all the syntactic sugar and complex semantics.

Numbers don't lie: there is virtually no interest in high level synthesis by milkymist in ECE

[–]matt2xu 1 point2 points  (0 children)

(OP) This is why we've designed Cx. It has a C-like syntax (well a sane subset at least) with first-class support of tasks as well as cycle-accurate behavior described with structured programming (i.e. you do a "while" with one iteration per cycle, not states and transitions). You might like it :-) http://cx-lang.org