Forth (e.g. Mecrisp-Stellaris) on a Zynq?

[rhb]

I've finally recovered from a major expansion of my lab and am returning to work on my FOSS DSO FW for Zynq based DSOs project  At present I am reading the "Zynq Book".  Something in that sparked an intriguing idea, forth on a Zynq.  Mecrisp would be the obvious place to start as there are many ARM ports of it.

Naturally, forth won't support VHDL or Verilog and such with a reasonable amount of effort, so the FPGA fabric would have to be programmed in RTL, but the incremental development nature of forth might make that actually quite tractable.  In particular I'm thinking of this in the context of dynamic partial reconfiguration of the FPGA fabric.  For example, one might build a DSP pipeline by invoking a series of forth words which loaded the elements of the pipeline into the PL.

This would have the benefit of making Zynq development independent of the Xilinx toolchains. It would also give complete control of how PL resources ere allocated.

[tggzzz]

Synthesis is easy.

Place and route is the problem.

Good luck getting away from Xilinx tools for P&R.

[rhb]

Are you familiar with forth?  It's a *very* bare metal world.  It probably would not be as efficient in the use of the PL real estate as Vivado and would certainly require intimate familiarity with the PL structure.

For the sort of application I'm thinking of, the place and route should not be that complex.  The DSP blocks are where they are.  You're not synthesizing those, just wiring them to suit.  So really all you're doing is routing.

[tggzzz]

Are you familiar with forth?  It's a *very* bare metal world.  It probably would not be as efficient in the use of the PL real estate as Vivado and would certainly require intimate familiarity with the PL structure.

For the sort of application I'm thinking of, the place and route should not be that complex.  The DSP blocks are where they are.  You're not synthesizing those, just wiring them to suit.  So really all you're doing is routing.

I first designed silicon and used Forth in the early 80s

Are you familiar with the Vivado toolchain?

[iMo]

I've spent a lot of time with Forth (amforth, flashforth, mecrisp on stm32 and ice40). A great dev tool for people who like to be pretty close to the hw. Writing a "word" which would reconfigure the FPGA's fabric around the Zynq (running the Forth interpreter) would be an effort of a size I can hardly imagine..

[rhb]

The sort of application I have in mind is a DSP pipeline.  So it's really just wiring up adders and multipliers with coefficients in the local memory blocks.  That's several orders of magnitude simpler than the typical the typical FPGA configuration problem.

All the forth word would do is load a bitstream into the appropriate section of the FPGA.   You reserve as many reconfigurable blocks as you want making sure they will accommodate everything you want to load into them.  Then you copy the bitstream to that block. That's not a major task.  Developing the bitstream is more work, but FIR and IIR filters are not all that complex.  In seismology we aren't constrained to real time, so we just do an FFT, apply the filter and back transform.  That approach is rather more difficult to do in real time.

My  motivation for the FOSS DSO FW is that I am fed up with buggy crap from even the tier A OEMS.  So far as I know, the only DSO that will display a hysteresis plot is the LeCroy.  All the others will compute the integral of CH2, but you can't select the output of a math function as an input to an XY display.  So to make a hysteresis plot you have to make an analog integrator.  That's a classic example of design by people who don't actually use what they are designing.

I had been planning to implement the FOSS DSO FW in C and Verilog.  I'm certainly going to try that just to leanr what it is like.  But the more I consider using forth the more attractive it gets.  I'd need to use one of the ARM cores to run Linux just for the USB and filesystem support, but using forth on the other core looks quite appealing.

Odd thing is that I haven't used forth much and almost not at all in 35 years other than using Mecrisp to generate PWM for prototyping an LCR meter which I haven't built.  The only significant forth project I did was a decompiler.  The forths I had on the Vic20 and C64 were so buggy and badly documented that I could not do anything until I had done that.  Then I went back to school and everything I did was on an 11/780 with an FPS-120B and I found myself tasked with administering a MicroVAX II in a BA123 worldbox.  No training, no support, must work.

But recent discussions on the Mecrisp mailing list showed that I understood the logic of forth better than people who had been using it for several years.  That was principally the result of my understanding how  operating systems, compilers and linkers work. Forth is different, but it's not that different.  It still has to deal with the hardware.

The FPGA gives the user a wirewrap view of the hardware.  For my purposes that's actually an attractive model. Ultimately the only way to find out is to try it.

I'm glad to find a familiar name and a new name with interest in the concept, even if skeptical.

[tggzzz]

Oh, I understand your concepts and the principles behind them.

To check the practicality, I suggest you install vivado and try taking a trivial design through to a bitstream.

I'll note that a principal USP of the Zync devices is to have an intimate entwining of hardware (the PL) and software (the PS). If you don't have the ARM-based PS, then consider using an Artist device.

[iMo]

You have touched several issues I would consider the CSFs:
1. Forth - today a rather exotic stuff. Mecrisp is one of the best Forths I know and MatthiasK is definitely the guy who is able to port it to Zynq. Is he ready?
2. The Forth dev base is extremely small, however, like one two three four.. So do not expect a large network of volunteers starting with a steep development because you think it is a good idea..
3. Xilinx - ask the guys messing with IceStorm project - still experimental and way not as efficient as the today's Lattice dev tools - what an effort they spent already.. And mind the iCE stuff is the absolutely simplest FPGA arch you may imagine.
4. Afaik the all existing FPGA related open dev tools are not Forth friendly.

[Bassman59]

If you don't have the ARM-based PS, then consider using an Artist device.

typo (or auto-uncorrect)! It's the Artix. Just so rhb can actually find the parts on the Xilinx web site.

[tggzzz]

If you don't have the ARM-based PS, then consider using an Artist device.

typo (or auto-uncorrect)! It's the Artix. Just so rhb can actually find the parts on the Xilinx web site.

<Expletives deleted>. Thanks

[andyturk]

Something in that sparked an intriguing idea, forth on a Zynq.

Why forth? Just curious.

A LISP would probably be as easy to implement.

[tggzzz]

Something in that sparked an intriguing idea, forth on a Zynq.

Why forth? Just curious.

A LISP would probably be as easy to implement.

C, in the form of System-C, even easier

You could even get clues as to what is practical, without reinventing the wheel.

[radioactive]

Just in case this might be useful at some point:

https://github.com/SymbiFlow/prjxray
https://symbiflow.github.io/prjxray-db/#project-x-ray-xilinx-series-7-bitstream-documentation
https://symbiflow.github.io/prjxray-db/artix7/

[rhb]

1) I have a Zybo Z7-20, MicroZed, DE-10 Nano and a BeagleBoard X15.  So I am well equipped in the hardware department.  That does not count a pile of MSP430 and ARM boards which already have Mecrisp installed or available.

2) I have Vivado installed in a Windows VM, but decided that I really needed to run that on bare hardware, so I have a Win 7 instance and am going to be installing 18.3  on Debian shortly along with the Cyclone V dev tools.  I hope to make Debian my primary dev platform for all things which will run on Linux.  My mainstream DSP system is Solaris 10 u8 which I keep offline on an isolated network as it is old and vulnerable.  But the Sun/Forte development tools are the best I've used and I have a fair number of customizations implemented for that.

3) I like forth.  It is elegant.  It is both an operating system and a language and was created specifically for embedded development. I know of no other system that is self hosting on minimal hardware.   Forth will let you test your code and *then* compile it.  So far as I know, everything else is the opposite.

 I use FORTRAN for numerical work,  awk for string processing and C for systems work.  So it is natural for me to choose a language for embedded work designed for the task.  If it proves awkward I can always switch to C.  I doubt that I'll need to do that.

A large part of the appeal of forth for this is it gives me bare metal control.  That is not provided by  Vivado.  They are attempting to solve an NP-hard problem by means of various heuristics.  You do not know what it will do.  I don't intend to try to use every last gate.  Just what fits the task conveniently.

When I think about a computer or software running on one, I think about it in terms of what is going on at the wire and gate level, not at the language construct level.  For someone with that viewpoint, forth is a natural fit.  I look at the FPGA as a big wirewrap frame with lots of parts waiting to be connected.  For that, the designer takes responsibility for the timing.  Seymour Cray cut all the wires the same length. I shall need to do the same.

I wouldn't dream of asking Matthias to port Mecrisp to the Zynq.  He's finally finished his PhD after far too many years.  He needs to devote himself to his profession, not his hobby.  I'm sure I'll have some questions, but he has always been very gracious in all the years we have corresponded.  Besides, I'd be embarrassed if I could not do this on my own, though in all fairness his inner interpreter scares me a bit as it is more complex than the model I learned 35 years ago on a 6502.

Before I start on forth on the Zynq I'm going to work through the Zynq tutorials for the MicroZed.  That is what I bought it for.  After I got the Zybo I was rather put off reading "this example is unsupported" comments.  That screams "prima donna" to me.  Having worked with such people, I don't like them.  Avnet cares a lot more about their user base.

[andyturk]

C, in the form of System-C, even easier

You could even get clues as to what is practical, without reinventing the wheel.

This System-C?

[tggzzz]

C, in the form of System-C, even easier

You could even get clues as to what is practical, without reinventing the wheel.

This System-C?

Or https://www.xilinx.com/products/design-tools/vivado/integration/esl-design.html

There's been a whole ecosystem of programming-language=>HDL systems over the decades. Since they seem to peter out over time, I haven't kept track of exactly which ones have mutated and are still being used. Hence the two links may or may not correspond to the same thing.

Either way, the OP could learn where the pain points are, without having to reinvent them and add new ones.

[rhb]

Matthias pointed me to this:

https://prjxray.readthedocs.io/en/latest/

and after a brief perusal of that I *won't* be trying to program the FPGA by hand.  I'll let Vivado generate bitstreams and just use forth to load them.  And that's provided Xilinx  doesn't have closed source code for loading them into the FPGA that you have to use.

I've spent too much time reverse engineering undocumented data formats already.  Far too many people have walked in my office with a tape they insisted had to be read ASAP but for which they could provide no information.  Dumping tapes in hex one record at a time is no fun no matter how well you are being paid. 

[tggzzz]

Matthias pointed me to this:

https://prjxray.readthedocs.io/en/latest/

and after a brief perusal of that I *won't* be trying to program the FPGA by hand.  I'll let Vivado generate bitstreams and just use forth to load them.  And that's provided Xilinx  doesn't have closed source code for loading them into the FPGA that you have to use.

I've spent too much time reverse engineering undocumented data formats already.  Far too many people have walked in my office with a tape they insisted had to be read ASAP but for which they could provide no information.  Dumping tapes in hex one record at a time is no fun no matter how well you are being paid.

A sound decision

There are degrees to which the Zynq can change its operation during its operation, but unsurprisingly there are limits too. I'm not sure of the benefit of "Forth loading them"; you may have to define your objectives and then decide whether that is the best way of achieving them.

[rstofer]

'and after a brief perusal of that I *won't* be trying to program the FPGA by hand.  I'll let Vivado generate bitstreams and just use forth to load them.  And that's provided Xilinx  doesn't have closed source code for loading them into the FPGA that you have to use.

This may not be the current thinking but multiple configurations has been done for a very long time.  Usually, all of the configurations are stored in the platform flash but, as there are alternatives to the platform flash, I suspect you can store multiple configurations on any medium that can serve the image to the chip.

https://www.xilinx.com/support/documentation/sw_manuals/xilinx11/pim_t_multiple_bitstream_configuration.htm

Google may be a big help.  I know there are projects that use a uC to serve up the images.

[rhb]

The forum software just informed me there was a new post to the thread, 4 months after the fact.  Go figure.

I'm afraid I bought so much T&M gear that I'm still in the "get in in a rack" mode as I ran out of space.

[tggzzz]

The forum software just informed me there was a new post to the thread, 4 months after the fact.  Go figure.

Look at the top left of the page, just under the "Hello rhb". The "Show new replies to your posts" works well, and is what you need.

[rhb]

You're being slow.  That is what I did.  And a thread in which the last post was January showed up.  I routinely check recent posts and mark the threads as read.

[iMo]

As a proof of concept for your ideas you may try to mess with iCE40HX8k or iCE40UP5k.
There is a Mecrisp Forth port running on it (I've been using it since ever) and those FPGAs are supported (and reverse engineered) by the IceStorm open source tools. Thus you have everything handy for your experiments.
HTH.

[ebastler]

You're being slow.  That is what I did.  And a thread in which the last post was January showed up.  I routinely check recent posts and mark the threads as read.

Never mind; that notification was simply an artefact of Dave's re-organization of forum categories. "FPGAs" and "Microcontrollers" were split into two separate categories. Several users have mentioned that Dave's moving of threads has triggered spurious notifications of new posts.

[jmelson]

  I'll let Vivado generate bitstreams and just use forth to load them.  And that's provided Xilinx  doesn't have closed source code for loading them into the FPGA that you have to use.

No problem, all you need is 4 controllable lines to activate the JTAG port.  Xilinx does have some docs that show how to use a processor to bit-twiddle the JTAG port to download an FPGA configuration.  That part hasn't changed in about 4 generations.

Jon