programming some FPGA using Espruino/Pico

Hello there!

I was wondering how much work it may take to have a way to be able to program a FPGA [ using SPI ? ] from an Espruino ?

It may need a different set of "helpers" for different manufacturers/devices, yet a module could provide some overall architecture that may then support specific hardware ( .. )

Seeing the following fleafpgauno or fpga-shield, I wondered what it 'd take to replace the Arduino/AVR sid by a Pico ;)

So, possible ? already exist ? [ actually useful ? ] hints ? ^^

( or XC6SLX9 ebay ? )

I had a look at those, looks like the fleafpgauno IS the arduino, it's an fpga emulating an arduino compatible chip. The shield is programmed by an arduino, but as far add I can tell it only interfaces with the flash, you still need to use your computer to create the bitstream for the fpga. I don't think there's any value in replacing the arduino with an espruino, it's just doing some translation and you don't interact with it at all.

I've previously wondered whether it'd be possible to write javascript and have it translated into logic and programmed into an fpga, but due to the bulky toolchains needed for fpgas and the difficulty in mapping javascript to some sort of hdl, it seemed like a lot of effort for very little gain.

Well, I think it should be possible. It'd totally depend on the type of FPGA what you had to do to get it to work, but I'm sure you could send configuration data over.

I think it'd be hard to get the JS to modify the FPGA directly, but you could have several different configurations in flash or an SD card and you could write the required one in as needed.

... I actually used to work for Altera, developing a compiler that made C code run on an FPGA. You could definitely get some subset of JS running on an FPGA, but it'd require a lot of work, and the compiler for that is never going to fit on Espruino itself :)

Also it's really not (at least when we did it) a matter of just running code directly on an FPGA and it being faster. If you want to get any kind of performance you've got to think really hard about exactly how your code maps onto the hardware (adds, multiplies, etc) when you write it.

Did you have anything particular in mind that you wanted to use it for?

Oh man. I'm also interested in what you wanted to use this for :)

I think the way to go would be to use the Espruino as a SPI interface to it's configuration memory. Have a look at the fpga-shield and the build log :)

There are things like SystemC and other CtoHDL projects that I've found utter crap after trying anything but the samples they provide. They're fun and all, but even for an amateur like me, you quickly get to a blocking point.
Did the project you worked on @Gordon compile C into opcodes for a soft core, or did you try to make a C to HDL thingy?

I like how pshdl.org approaches things. I've not tried it yet.

In the end, FPGAs are configured; not programmed.

The thing I worked on did both actually - it'd create HDL based on the code you provided, and would make opcodes for that special soft core, but in a relatively optimised way.

It gave a neat little report of all the ALUs and their usage each clock cycle, and then you could use macros to give the compiler hints, like 'do this add on that adder unit'.

... so it effectively let you design the processor and a VLIW code in parallel. As I understood it, it made it into Altera's set of tools soon after I left - but it's been 10 years since so I have no idea what's happened to it now!

Sounds very cool. Sounds like an even more adaptive Nios 2 softcore + compiler? Interesting stuff this is :)

Kind of - as far as I remember there was no actual description of the core, it was just one C++ file. I guess rather than a CPU designer, it was more of a way of designing hugely pipelined systems (while validating them very quickly by compiling to C).

Every variable represented a register and you could define how many bits was in each one, and what was attached to them (multiply, add, etc). Then, if you do myvariable = a*b it'd do a multiply using that multiplier (and any maths that you didn't tag would get assigned to the most suitable ALU available, or one would get made).

While you could just write C, you had to be prepared to look at the reports of hardware utilisation to get something working well - but when you did you could make something really fast and efficient - because you were designing a pipelined system you could get the clock rate right up near the maximum the FPGA could handle, with pretty much full utilisation.

I wish I could find it now, but I did a quick google and came up blank :(

It's the kind of thing that'd be really cool now - with that little bit more processing power it could run the compiler in the background and could give you a live update of exactly how your code mapped to hardware.

"wow" ^^ !

I'm overwhelmed by all those great answers ;)

@alexanderbrevig "FPGAs are configured; not programmed." -> indeed, and maybe I'm too scared to digg in lengty docs .. although I'll sure take a look at the fpga-shield & build log stuff :)

If I actually had any free time, I'd love to reimplement what we'd done at Altera, but as an online tool using JS. It'd be a lot easier given all the nice parsing and type inference tools there are now.

Sadly I don't have time, and Altera (being a US company) would probably sue the hell out of me if I did :)

;)

This new tool creates fpga logic in JSON before turning it into Verilog. Getting closer? http://hackaday.com/2016/02/23/icestudio-an-open-source-graphical-fgpa-tool/

I suppose it wouldn't be so hard to fire off JSON to a server to transform into a bitstream, kind of like compiled code on the espruino.

Hi there !

+the1laz
thanks !
I did see this & sent myself a mail to digg it, but yet didn't took the time to even watch the video ..
.. and I just did: this tool seems pretty cool, especially when I saw the code tab pop ;)

'll have to digg that too :)

nb: I'd love to see some algo that organizes the mess left once you've done some concluding tests with the FPGA used ( not personally a fan of "linked nodes" UIs, but maybe it's caused by some known nib builder .. ;p )