Forth (e.g. Mecrisp-Stellaris) on a Zynq? - Page 1
Forum section: electronics / general

author: rhb
author_rank: Super Contributor
timestamp: January 20, 2019, 03:26:56 pm
content: 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.

author: tggzzz
author_rank: Super Contributor
timestamp: January 20, 2019, 03:42:56 pm
content: Synthesis is easy.Place and route is the problem.Good luck getting away from Xilinx tools for P&R.

author: rhb
author_rank: Super Contributor
timestamp: January 20, 2019, 04:38:25 pm
content: 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.

author: tggzzz
author_rank: Super Contributor
timestamp: January 20, 2019, 04:57:01 pm
content: Quote from: rhb on January 20, 2019, 04:38:25 pmI first designed silicon and used Forth in the early 80sAre you familiar with the Vivado toolchain?

author: iMo
author_rank: Super Contributor
timestamp: January 20, 2019, 05:03:00 pm
content: 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..

author: rhb
author_rank: Super Contributor
timestamp: January 20, 2019, 07:14:38 pm
content: 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.

author: tggzzz
author_rank: Super Contributor
timestamp: January 20, 2019, 07:31:32 pm
content: 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.

author: iMo
author_rank: Super Contributor
timestamp: January 20, 2019, 07:48:35 pm
content: 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.

author: Bassman59
author_rank: Super Contributor
timestamp: January 20, 2019, 07:49:22 pm
content: Quote from: tggzzz on January 20, 2019, 07:31:32 pmtypo (or auto-uncorrect)! It's the Artix. Just so rhb can actually find the parts on the Xilinx web site.

author: tggzzz
author_rank: Super Contributor
timestamp: January 20, 2019, 07:53:13 pm
content: Quote from: Bassman59 on January 20, 2019, 07:49:22 pm<Expletives deleted>. Thanks

author: andyturk
author_rank: Frequent Contributor
timestamp: January 20, 2019, 09:01:32 pm
content: Quote from: rhb on January 20, 2019, 03:26:56 pmWhy forth? Just curious.A LISP would probably be as easy to implement.

author: tggzzz
author_rank: Super Contributor
timestamp: January 20, 2019, 09:23:57 pm
content: Quote from: andyturk on January 20, 2019, 09:01:32 pmC, in the form of System-C, even easierYou could even get clues as to what is practical, without reinventing the wheel.

author: radioactive
author_rank: Regular Contributor
timestamp: January 20, 2019, 09:38:55 pm
content: Just in case this might be useful at some point:https://github.com/SymbiFlow/prjxrayhttps://symbiflow.github.io/prjxray-db/#project-x-ray-xilinx-series-7-bitstream-documentationhttps://symbiflow.github.io/prjxray-db/artix7/

author: rhb
author_rank: Super Contributor
timestamp: January 20, 2019, 10:24:36 pm
content: 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.

author: andyturk
author_rank: Frequent Contributor
timestamp: January 21, 2019, 03:08:49 pm
content: Quote from: tggzzz on January 20, 2019, 09:23:57 pmThisSystem-C?

author: tggzzz
author_rank: Super Contributor
timestamp: January 21, 2019, 06:47:23 pm
content: Quote from: andyturk on January 21, 2019, 03:08:49 pmOrhttps://www.xilinx.com/products/design-tools/vivado/integration/esl-design.htmlThere'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.

author: rhb
author_rank: Super Contributor
timestamp: January 21, 2019, 08:52:06 pm
content: 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.

author: tggzzz
author_rank: Super Contributor
timestamp: January 21, 2019, 09:24:31 pm
content: Quote from: rhb on January 21, 2019, 08:52:06 pmA sound decisionThere 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.

author: rstofer
author_rank: Super Contributor
timestamp: January 23, 2019, 02:24:32 am
content: Quote from: rhb on January 21, 2019, 08:52:06 pmThis 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.htmGoogle may be a big help. I know there are projects that use a uC to serve up the images.

author: rhb
author_rank: Super Contributor
timestamp: May 30, 2019, 07:41:02 pm
content: 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.

author: tggzzz
author_rank: Super Contributor
timestamp: May 30, 2019, 08:18:48 pm
content: Quote from: rhb on May 30, 2019, 07:41:02 pmLook 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.

author: rhb
author_rank: Super Contributor
timestamp: May 31, 2019, 12:30:45 am
content: 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.

author: iMo
author_rank: Super Contributor
timestamp: May 31, 2019, 07:16:18 am
content: 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.

author: ebastler
author_rank: Super Contributor
timestamp: May 31, 2019, 02:58:27 pm
content: Quote from: rhb on May 31, 2019, 12:30:45 amNever 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.

author: jmelson
author_rank: Super Contributor
timestamp: May 31, 2019, 10:11:15 pm
content: Quote from: rhb on January 21, 2019, 08:52:06 pmNo 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

author: rhb
author_rank: Super Contributor
timestamp: June 01, 2019, 01:00:08 am
content: Quote from: jmelson on May 31, 2019, 10:11:15 pmThank you. I had assumed from what I'd read and the basic nature of the task it was doable. But it's nice to have confirmation.Unfortunately, at the moment I'm running electrical power in my wood and metal shop building.

author: brucehoult
author_rank: Super Contributor
timestamp: June 01, 2019, 04:53:59 am
content: Quote from: rhb on January 20, 2019, 07:14:38 pmI'm not so sure that's practical without a multi-MM effort.What you *could* do easily is make up a Verilog/VHDL design in the conventional way, build in a lot of multiplexors, and expose the control lines for the multiplexors in registers that code running on the ARM can write to.You could do quite a lot of instant runtime re-configuration without trying to muck about with doing partial bitstream loading yourself.

author: rhb
author_rank: Super Contributor
timestamp: June 01, 2019, 11:53:03 am
content: I'm concerned about doing this with the limited DSP resources of the smaller parts.I really haven't thought about this in quite some time. I've been consumed by setting up my lab and shop facilities. I'm working on the electrical service in my shop at the moment. That involved sorting a large quantity of conduit fittings, boxes, etc that Dad left me.But between starting on the FPGA project and now I went on a major TEA binge and have an 8753B/85046A, 8566B and Tek 11801 sitting in my living room for lack of a rack. I now have a *really* nice T&M stack, but also lots of chaos as a result.I've been dealing with a lot of, "Before I can do A I need to do B, but that means I'll have to do C and D".Fortunately it's all just for fun and most of it is interesting. Finding and sorting stuff is just tedious.

author: RFI
author_rank: Newbie
timestamp: January 23, 2024, 10:30:10 am
content: Well hello, in the interest of FORTH on a Zynq, I found this thread so I thought I might resurrect it and see if there is still interest.I came here by way of discovering Zepto Forth, which runs on a Cortex-M and works well apparently on a Pi Pico see here:https://youtu.be/ri0VXzS5fiwSo I have heard a lot of talk about FORTH soft processors written in RTL, but why not run it on the Zynq ARM processor and interface to other stuff in the FPGA fabric (PL) ?Otherwise I have been ocnsidering just using a Pi Pico and interface it to an Artix.Any thoughts on this? Has anyone tired it or interested in trying it?At this point I am questioning the value of any RTL Forth soft processor at all.Who has experience interfacing Forth to an FPGA PL fabric that might comment on this? I need a way to read write RTL registers to control PL designs and an external Pi Pico seems like the simplest cheapest way to go about it, or possibly the same Zepto FORTH running on a Zynq ARM.Thanks and regards.

author: iMo
author_rank: Super Contributor
timestamp: January 23, 2024, 10:59:11 am
content: I did with MecrispForth on the stm32F407, and with MecrispIce on the 16bit J1a forth cpu in ice40UP5k fpga (the first UP5k port actually, afaik). The enhanced j1a is a special stack cpu designed for Forth. Interfacing with 16bit wide "something" inside the fpga is rather easy, provided you spend some time with the stuff and you learn how it works. Otherwise I spent a lot of time with AmForth, FlashForth, and a pic32 based forth (I forgot the name of it). Mind the forth community is rather small and availability of libraries or ready to run code is limited to basic stuff (I assembled a 48bit floating point lib for Mecrispforth). Everybody writes his/her own words, reading/modding/debugging the sources with someones words is difficult unless you are almost at expert level.