HN user

morrad

47 karma
Posts0
Comments17
View on HN
No posts found.

As someone who regularly writes RTL for FPGAs during their day job, I like the idea, but am skeptical about the follow through.

For years now, various companies have tried to make cross compilers to be able to synthesize C style code into RTL. The name for this basic idea is "High Level Synthesis" (HLS). For applications like digital signal processing, HSL is actually decent. Having a stream of data moving through some transform is easy to express in C (and OpenCL), and easy to translate into a relatively efficient data pipeline in RTL when compared with making one "by hand". But this isn't the only thing that is going on within the FPGA. It is clunky and inefficient to create state machines or controllers, interact with inbuilt memory blocks, or interface with other modules not built in the HLS language.

Since inefficiencies cost resources, you end up trading your decreased development time through using HLS for possibly increased device costs, and some ambiguity in terms of the architecture of the hardware your synthesize. Since these tools haven't been broadly embraced by the FPGA coding community, the support for them doesn't tend to last long either.

Thanks for the correction. I'm on the hardware side of things, so my understanding was that the "allowed" algorithms were actually required, and I'm relieved to hear that's not the case.

My understanding is the FIPS requires that the SSL library implements a certain suite of protocols (including the Dual EC DRBG discussed in the linked mailing list post) which have known cryptographic weaknesses.

it has an incredibly sophisticated and powerful content-matching engine that does monitor what's being uploaded, and automatically checks new videos against a giant corpus of known copyrighted works

This is above and beyond the requirements of the DMCA though. Doing this isn't what makes Youtube legal, it just attempts to appease copyright holders.

automation is intended to eliminate [jobs]

Automation has the potential to eliminate jobs, but also has the potential to allow much more work to be done by a single person, or allowing that person to do the same work with less effort.

Perhaps I'm overly simplifying your words, but I don't think automation is inherently "evil". Like all tools or techniques, they may be used toward good or bad ends.

There are better (less expensive) ways to build credit than car loans.

While I don't remember the name, my wife and I built credit getting some sort of secured loan from our local credit union. The process was something along the lines of making an account with them, putting $X into the account, and then getting a 6 or 12 month loan from them for the same $X dollars at a really low interest rate. Overall I think we paid $30 to $50 dollars over that period in interest.

I'm late to this discussion, but as a "real pro" VHDL coder, I can at least sate your curiosity.

At my company, we abstract the vendor specific implementations to have a common interface that we can then use to keep the rest of our code vendor neutral.

For example, within the "Dual Port RAM" section of our revision control system, we have separate files that instanciate memory control blocks for Xilinx Spartan and Altera's Cyclone FPGAs, and generalize the interfaces so that all I see when creating a design is a vendor agnostic "dpram" component interface. When I need to use one in our design, I just need to import the correct file into my build corresponding to the actual FPGA that will be used. Migrating to another vendor involves changing which file gets during synthesis.

Cheers.