Software Emulation of PASM code
Wossname
Posts: 174
One thing I have always wanted since I began using PASM for programming the P8X32A is a software emulator.
I have looked around and have not found such a thing (if anyone knows of one *please* let me know).
So I thought I'd write one myself. Why? Because of convenience mainly, I do like to write code when I'm away from the electronics bench, and it would be really nice to just throw quick ideas into an emulator without having to rummage through my equipment to see if it works or not.
I'd like to get your opinions on what you think of the following idea for Propeller PASM emulation software...
Overview:
A command-line tool (linux/windows etc.) that accepts a PASM code file as input and is able to step through the code and halt at user-defined breakpoints and output debugging information such as register states.
The initial release could have the following features (eg. the low-hanging fruit):
Later versions might also have these features:
I'm fairly familiar with the PASM language and the Prop's architecture (not so much SPIN to be honest, so I doubt that'll included until *much* later).
I'd like to hear your thoughts on whether you'd be interested in such a tool (or do you think it's a complete waste of time?).
I have looked around and have not found such a thing (if anyone knows of one *please* let me know).
So I thought I'd write one myself. Why? Because of convenience mainly, I do like to write code when I'm away from the electronics bench, and it would be really nice to just throw quick ideas into an emulator without having to rummage through my equipment to see if it works or not.
I'd like to get your opinions on what you think of the following idea for Propeller PASM emulation software...
Overview:
A command-line tool (linux/windows etc.) that accepts a PASM code file as input and is able to step through the code and halt at user-defined breakpoints and output debugging information such as register states.
- Open Source (GPL or MIT or whatever is most suitable) and free ($0.00)
- Command-line interface to make scripting and automation easy
- Written in Gnu99 standard C language (portable to any platform). I am also considering the Ada language as a possibility.
The initial release could have the following features (eg. the low-hanging fruit):
- Support limited to a single Cog.
- 'Watchers' for automatically pausing execution when a condition is met ("break when VariableX == 0x0001be7d)
- Simple interactive commands like "dr" (dump register values), "0x19?" (print value is in cog ram offset 0x19) etc...
- Takes a "stimulus" file as input ("wait 2417998 cycles then set PORTA[4] HIGH.....")
- Other stuff (any suggestions welcome)
Later versions might also have these features:
- Full 8 cog support with correct handling of GPIO sharing / state detection
- Hub operation support with accurate round-robin sequence emulation
- Logic-analyser output (generate "GPIO pin states and internal register states over time" data that can be plotted as a graph (Excel or GnuPlot or whatever)
- Accurate counter (CTRA/CTRB et al) support
- More elaborate breakpoints that can wait for specific events on specific cogs or even the Hub itself ("break when any cog attempts to access a Hub resource X or Y")
- Pass in a "normal" propeller image and it will be disassembled back into PASM source code and run in the emulator. (I actually already wrote a mostly-working disassembler a few years back)
- Pixel correct VGA / PAL / NTSC generation simulation for those writing video games
- Other stuff (any suggestions welcome)
I'm fairly familiar with the PASM language and the Prop's architecture (not so much SPIN to be honest, so I doubt that'll included until *much* later).
I'd like to hear your thoughts on whether you'd be interested in such a tool (or do you think it's a complete waste of time?).
Comments
Jim
https://sourceforge.net/projects/gear-emu/
https://github.com/parallaxinc/spinsim
If you're going to create something new, I wonder what it would take to make it possible for GDB to connect to it. I'm imagining being able to use something like propeller-load or propload to program the emulator and then connect to the emulator with GDB such that I can step through the code in my IDE while controlling the pins through this new tool's interface as well... that would be really powerful.
You brought up the ability to stimulate the pins with an input file. Most of the time what I need help debugging is serial communication interfaces like SPI and I2C, so a file that just says "pin1 high, pin 1 low" would be really tedious. It'd be a lot better if the emulator understood a few basic protocols like UART, I2C, and SPI and allowed the author to input scripts using these protocols.
Also, can I encourage you to pick a higher level language than C to start with? Python and Java would be two fine languages. C# maybe if you prefer native binaries over interpreted. With Linux's mono, it should be possible to make it cross-platform even. Perhaps Ada also fits these requirements - I don't know since it's still foreign to me.
Good luck! I look forward to hearing more about this
The link above is to the GPLed source. Am I missing something?
Nope, probably the other way around. I must be thinking of something else. That's great
Encouragement is to be encouraged
However, I do appreciate the C# / Mono argument. Yes, I think that would be a lead worth pursuing. I have had some dealings with that in the past (like 10 years ago, I hope things have improved since then, comments welcome on this topic).
Also bear in mind the fact that it's PASM that we wish to simulate/emulate. Staying close to the "bare copper" (as C can often do with minimal effort) is beneficial.
It's hard to argue with C. *
*Or C++ if I'm feeling charitable.
Others have pointed you to Gear, I just want to add that I ported the code to C++, if you are interested I can clean it up a bit and post the source here. It is not optimized and doesn't support all the features of Gear (mainly the plugins) and doesn't have an UI. It works, as far as I can tell, at least with Spin and PASM, for some reasons it doesn't work when I feed it a C program. It is very slow, as it is Gear, I was hoping that a C++ porting would gain some speed but it is very far from being realtime or even useful at all. If you know some method to speed it up, it would be great!
I first explored Gear - It uses a C# and is pretty nicely done but it's performance is linked to an internal clocking system that is hard to improve much. The Gear SPIN emulator is also quite nicely done with faster potential performance but only for SPIN only programs. I don't use SPIN but have come to appreciate the idea behind SPIN - if parallax had invested more in their software tools it might have gone further faster.
The real PITA is the poor support for debugging from the spin generation tools. I looked quite hard to find symbol tables etc that I could plug back into the Gear to generate the debug information I was after but came up empty.
I tried to understand the C++ openSIM version of the x86 (really!?) original compiler to try to figure out how to generate the debug info I was after and ended up giving up and writing my own PASM code emulator instead.
I think before writing a PASM simulator it would be worthwhile figuring out how to generate the debug information to use with the output of the SPIN. There were some other 3rd party efforts but they seemed unmaintained and I couldn't get them to run. Maybe I just missed something but debug info would the first step before taking the time to write a sim.
If you can get a C# implementation running at near real-time with debugging support I can wrap an IO footprint and plug it into Virtual Breadboard (www.virtualbreadboard.com) with integrated editing and code edit with debug support which is why I was exploring Gear in the first place.
That is a very generous offer, macca. However, I'm not looking to adopt or port and existing project.
I'm hoping to make something small, simple and utilitarian, but useful. I don't like the idea of having a huge GUI overhead (sounds like an endless porting nightmare).
Happily! It will be easier to write, read, and maintain. C doesn't know what a "string" is, so any language with a real string type will be a big jump right there. Any object-oriented language would be another big jump (assuming you're an OO guy and haven't jumped on the functional bandwagon). Garbage collection would be a nice addition as well, but that is certainly one of the things that could negatively affect performance. One might argue that speed is a primary concern, and a good reason to stick with C or C++, and maybe this is a good example of when language choice can actually make a difference... but it rarely does.
This would imply that dropping to a low-level language and dropping the GC didn't help much.
If language popularity is what you're after, JavaScript is the undisputed champion (please don't take this sentence seriously). StackOverflow's annual survey shows C and C++ are hovering around 20% popularity, compared to JS's 62% and Java's 40%. Python even beats C/C++ with a score of 32%. I can't speak for Ruby, R, Php, or F#, but I first learned Python (more than "Hello, world") back in 2011 and haven't had to undergo any major relearning since then. Of course there is the infamous Python 2 -> Python 3 discussion, but having learned on Python 2.7 the upgrade to 3.x was a piece of cake for me. Perhaps if you learned Python on 2.5 or less it's a bigger deal, but it has not slowed my work much at all. And if you went Java, that is quite backwards compatible. If you develop it in Java 8 or 9 today, it will continue running on future JVMs for many years to come.
I very much like the ideas and discussion so far in this thread. No matter your language of choice, I'll do my best to offer support in the form of ideas (and hopefully pull requests) in the future!
I'm not very familiar with C# but the emulator is mostly static code, the GC should never do anything. We are talking about emulating a thing that is running at an equivalent speed of 80x8=640MHz, even on a 3GHz processor you have about 18 clock cycles to emulate each instruction, not very much unless you code it in assembly (and I believe it will be very difficult even then).
Of course if you want to just emulate a single cog without any other feature (like PLL, counters, etc.) it will be much faster and maybe even realtime (haven't tested that).
Good point well made
I think C is a good fit for this project because it is a mature language which happens to also be ubiquitous and robustly documented. Plus it has simple data types that happen to correlate to the PASM model rather conveniently. C is also pretty much dominant in electronics at the level we're dealing with here.
Personally, I disagree.
The users/maintainers typically expected to use our hypothetical new tool would be conversant in languages common in very low-level electronics (C, Assembly, can't think of much else). This won't be a Spin simulator. Spin is a super high level language, rather problematical for us.
I don't know that many Python (or other VVHL language) developers also spend a lot of time writing assembly language. There are exceptions of course. This project is so niche it's ridiculous. Do we have the luxury of picking a VVHL language? No, I'm not convinced.
Speed performance had not occurred to me as a requirement in this project until you mentioned it. I had only considered that the (squishy human at the keyboard) would be manually stepping through their lines of PASM code one line at a time. Indeed, it is very likely that a user will, at some point, want to allow their code to run freely at full speed (20MIPS per cog let's say).
This needs more thought..................
A Prop1 chip running from a 5MHz external source, and a 16x PLL config will have a clock speed of 80MHz. Each instruction takes (waving hand in the air) 4 clock cycles, which gives 20,000,000 instructions per second per Cog.
Totally irrelevant though because the user will be using typed-in commands to trigger breakpoints and dumping register values all the time. I don't think anyone is doing Bitcoin hashing on a Propeller!
It would be desirable to run code at realistic speeds but I don't think it should be a project goal. Would be extremely cool though!
Spinsim also supports the P2, but I haven't updated it for about a year. I'm planning on updating spinsim to the latest version of the P2, but it will probably be a few weeks before I do that.
EDIT: BTW, the latest version of spinsim is 0.95. It's posted in the P2 Simulator thread.
Can that selection be a user-run-time-switch ?
Logging & peripheral simulation is always useful.
Can a variant of the SD peripheral, simulate the SPI boot device for P2 ? (and maybe i2c for P1 ?)
Yes, and no. Speed does matter, if the Simulator is so slow, users can more easily download and test.
Sometimes users want to run to some advanced code location, and then debug from there.
The simulators I'm used to, run between 10% and 100% of the MCU, and they have a deliberate cap on the 100%.
I tried one that was under 1%, and quickly gave up.
That means speed does need to be a project goal, tho hitting 100.0% is not that important.
Because speed matters, C is a reasonable choice...., at least for the Sim.Engine
however, there is another very different path to simulation, that may be even better.
A problem all simulators suffer from, is properly simulating everything. Opcode coverage is ok, but peripheral interaction quickly becomes important, and it consumes a lot of time testing the peripheral interactions on MCUs.
What the AVR does on their simulator, is use the Verilog as a base.
I believe they do Verilog -> C
This has a speed cost over a crafted core-sim, but it does buy you very good peripheral simulation.
This approach would also allow P2 Sim to be added, as well as P1 via P1V.
Given there are already software based simulators, would you consider looking into Verilog based sim ?
The Verilator:
https://www.veripool.org/wiki/verilator/
The Propeller Verilog:
https://github.com/parallaxinc/Propeller_1_Design
Also has the neat side effect that one can then transpile the C++ simulation into Javascript and run it in the browser.
An SPI flash chip should be fairly easy to simulate. In the P1 mode, spinsim already has the capability to boot from a file named eeprom.dat. It also simulates an I2C EEPROM, which allows reading and writing eeprom.dat.
I have played with VHDL recently and the tools are far from simple or lightweight. If Verilog is similar in nature then it sounds like it would be a maintenance-hard problem.
up C++ source code. The Verilator is entirely open source. However your generated simulator need not be.
Which VHDL tools have you played with? I only know that using Verilog from Altera Quartus is monstrous. Quartus is a huge and complex program. Quartus compilation is horrible slow. The editor is pretty poor. From what I read other commercial HDL tools are equally bad.
On the other hand the open source Icarus Verilog simulator is very light weight, quick and easy to use. It makes the edit, run, debug cycle of writing Verilog code as quick as hacking code in something like BASIC or Python.
I have not really tried the Verilator. I only compiled a little "hello world" verilog module with it a while back to see that it worked at all. Seems pretty straight forward.
I don't see that Verilog compiled with Verilator need be any more of a maintenance problem than code written in C++.
Still, we won't know what issues this approach might bring until someone tries it. Sadly I'm a bit too busy to experiment with such a thing just now.
I've dabbled with Xilinx ISE, Xilinx Vivado and Lattice Diamond in the past. I soon decided that life was literally too short to learn it in any detail. A total nightmare of insane complexity.
I think I understand the idea though... Use Verilator once to generate a lump of C++ code that represents the P8X32A and then we don't have to deal with the Verilog code ever again. The C++ lump becomes a "black box" which we shove some PASM code into and give it a clock source and some IO stimulus and let it run.
It does make sense.
Verilog itself though is pretty easy. For example, "Hello world" in Verilog:
module hello_world ; initial begin $display ("Hello World!"); #10 $finish; endKind of looks like any other programming language. The #10 is a bit odd but that just means wait ten time ticks before moving on.("$display()" and "#10" are not things you can use in synthesizing circuits but are very useful in writing test harnesses for you circuit modules.
The complexity comes form the fact that you are designing circuit elements that are supposed to be actual hardware and therefore there is a huge lot of parallelism going on. There are things in the language that can jar the mind of a software engineer at first sight though. For example:
module counter ( input wire clock, input wire reset, input wire enable, output reg [31:0] counter_out ); always @ (posedge clock) begin if (reset == 1) begin counter_out <= 0; end else if (enable == 1) begin counter_out <= counter_out + 1; end end endmoduleThose things that look like parameters to a function that gets called to a software guy are not really. They are wires connected to a circuit module. That hardware defined in the module will respond to changes on those wires at any time.That "always" is a bit odd to a software guy. It just means do something when the clock goes from low to high.
Let's test this counter module:
module counter_tb; reg clock; reg reset; reg enable; wire [31:0] counter_out; initial begin $display ("time\t clk reset enable counter"); $monitor ("%g\t %b %b %b %b", $time, clock, reset, enable, counter_out); clock = 1; reset = 0; enable = 0; #5 reset = 1; #10 reset = 0; #10 enable = 1; #100 enable = 0; #5 $finish; end always begin #5 clock = ~clock; end counter deviceUnderTest ( clock, reset, enable, counter_out ); endmoduleThat's not so bad is it? It's a module, it creates some registers and wires like declarations in other languages. It instantiates a counter as deviceUnderTest and hooks the registers and wires up to that device. It runs through some test steps wiggling reset and enable inputs. It monitors the input and output values.
A slightly tricky thing is that clock signal. That "#5 clock = ~clock" is running in parallel with everything else toggling the clock every 5 time steps.
Let's run that using the Icarus simulator:
Yay, it works.
All in all much like hacking code in Python. Quick and easy.
Next up, how do we compile that to C++ using Verilator? ....
This is my counter Verilog module:
module counter ( input wire clock, input wire reset, input wire enable, output reg [31:0] counter_out ); always @ (posedge clock) begin if (reset == 1) begin counter_out <= 0; end else if (enable == 1) begin counter_out <= counter_out + 1; end end endmoduleWe write a test harness for that in C++:#include "Vcounter.h" #include "verilated.h" #include <iostream> vluint64_t main_time = 0; // Current simulation time double sc_time_stamp () { // Called by $time in Verilog return main_time; } int main(int argc, char **argv, char **env) { Verilated::commandArgs(argc, argv); Vcounter* top = new Vcounter; // Set initial values of inputs top->clock = 0; top->reset = 1; top->enable = 1; while (!Verilated::gotFinish()) { if (main_time > 10) { top->reset = 0; // Deassert reset } // Toggle the clock. if ((main_time % 2) == 1) top->clock = 1; else top->clock = 0; // Run one iteration of our module top->eval(); main_time++; // Time passes... if (top->counter_out == 1000000000) { std::cout << "counter_out = " << top->counter_out << std::endl; // Read a output std::cout << "Done!" << std::endl; break; } } delete top; exit(0); }Compile the verilog counter into C++: Compile the generated C++ together with our C++ test harness: And run the resulting executable: Hmmm...six and a half seconds to run a billion cycles of our counter. Not bad.Looks like I have to try Verilator with my RISC V core...
That's right. Compile the Verilog once and use it as a black box in your C++ simulator.
The beauty of this is that it get's you an cycle accurate simulation of the whole Propeller, COGS, counters, HUB, I/O, video etc.
Looks like it might be fairly painless to compile the Prop Verlog, see above. Not yet sure about the resulting performance when building a whole Propeller though.
@KeithE,
I think the Verilator idea is a very interesting idea for the P2 as well.
Problem is we don't have the P2 Verilog to play with. It's probably not a good idea to disturb Chip with such notions at this time.
Did you look at the C code created ?
Yes, that suggests the code is working above register-level, at least.
If it is worked back to registers used, that's 32*1e9/6.5 = 4.923 GFlop, where Flop here means Flip-Flop equivalent.
Even at a 32b quanta, that's 153M/s
Look forward to those numbers....
Just the fact P2 exists in Verilog, is enough to pursue using already useful P1 emulation as proof of concept for eventual P2 flows.
Well OK, here you go:
// Verilated -*- C++ -*- // DESCRIPTION: Verilator output: Design implementation internals // See Vcounter.h for the primary calling header #include "Vcounter.h" // For This #include "Vcounter__Syms.h" //-------------------- // STATIC VARIABLES //-------------------- VL_CTOR_IMP(Vcounter) { Vcounter__Syms* __restrict vlSymsp = __VlSymsp = new Vcounter__Syms(this, name()); Vcounter* __restrict vlTOPp VL_ATTR_UNUSED = vlSymsp->TOPp; // Reset internal values // Reset structure values _ctor_var_reset(); } void Vcounter::__Vconfigure(Vcounter__Syms* vlSymsp, bool first) { if (0 && first) {} // Prevent unused this->__VlSymsp = vlSymsp; } Vcounter::~Vcounter() { delete __VlSymsp; __VlSymsp=NULL; } //-------------------- void Vcounter::eval() { Vcounter__Syms* __restrict vlSymsp = this->__VlSymsp; // Setup global symbol table Vcounter* __restrict vlTOPp VL_ATTR_UNUSED = vlSymsp->TOPp; // Initialize if (VL_UNLIKELY(!vlSymsp->__Vm_didInit)) _eval_initial_loop(vlSymsp); // Evaluate till stable VL_DEBUG_IF(VL_PRINTF("\n----TOP Evaluate Vcounter::eval\n"); ); int __VclockLoop = 0; QData __Vchange=1; while (VL_LIKELY(__Vchange)) { VL_DEBUG_IF(VL_PRINTF(" Clock loop\n");); vlSymsp->__Vm_activity = true; _eval(vlSymsp); __Vchange = _change_request(vlSymsp); if (++__VclockLoop > 100) vl_fatal(__FILE__,__LINE__,__FILE__,"Verilated model didn't converge"); } } void Vcounter::_eval_initial_loop(Vcounter__Syms* __restrict vlSymsp) { vlSymsp->__Vm_didInit = true; _eval_initial(vlSymsp); vlSymsp->__Vm_activity = true; int __VclockLoop = 0; QData __Vchange=1; while (VL_LIKELY(__Vchange)) { _eval_settle(vlSymsp); _eval(vlSymsp); __Vchange = _change_request(vlSymsp); if (++__VclockLoop > 100) vl_fatal(__FILE__,__LINE__,__FILE__,"Verilated model didn't DC converge"); } } //-------------------- // Internal Methods VL_INLINE_OPT void Vcounter::_sequent__TOP__1(Vcounter__Syms* __restrict vlSymsp) { VL_DEBUG_IF(VL_PRINTF(" Vcounter::_sequent__TOP__1\n"); ); Vcounter* __restrict vlTOPp VL_ATTR_UNUSED = vlSymsp->TOPp; // Variables VL_SIG(__Vdly__counter_out,31,0); // Body __Vdly__counter_out = vlTOPp->counter_out; // ALWAYS at counter.v:7 if (vlTOPp->reset) { __Vdly__counter_out = 0U; } else { if (vlTOPp->enable) { __Vdly__counter_out = ((IData)(1U) + vlTOPp->counter_out); } } vlTOPp->counter_out = __Vdly__counter_out; } void Vcounter::_eval(Vcounter__Syms* __restrict vlSymsp) { VL_DEBUG_IF(VL_PRINTF(" Vcounter::_eval\n"); ); Vcounter* __restrict vlTOPp VL_ATTR_UNUSED = vlSymsp->TOPp; // Body if (((IData)(vlTOPp->clock) & (~ (IData)(vlTOPp->__Vclklast__TOP__clock)))) { vlTOPp->_sequent__TOP__1(vlSymsp); } // Final vlTOPp->__Vclklast__TOP__clock = vlTOPp->clock; } void Vcounter::_eval_initial(Vcounter__Syms* __restrict vlSymsp) { VL_DEBUG_IF(VL_PRINTF(" Vcounter::_eval_initial\n"); ); Vcounter* __restrict vlTOPp VL_ATTR_UNUSED = vlSymsp->TOPp; } void Vcounter::final() { VL_DEBUG_IF(VL_PRINTF(" Vcounter::final\n"); ); // Variables Vcounter__Syms* __restrict vlSymsp = this->__VlSymsp; Vcounter* __restrict vlTOPp VL_ATTR_UNUSED = vlSymsp->TOPp; } void Vcounter::_eval_settle(Vcounter__Syms* __restrict vlSymsp) { VL_DEBUG_IF(VL_PRINTF(" Vcounter::_eval_settle\n"); ); Vcounter* __restrict vlTOPp VL_ATTR_UNUSED = vlSymsp->TOPp; } VL_INLINE_OPT QData Vcounter::_change_request(Vcounter__Syms* __restrict vlSymsp) { VL_DEBUG_IF(VL_PRINTF(" Vcounter::_change_request\n"); ); Vcounter* __restrict vlTOPp VL_ATTR_UNUSED = vlSymsp->TOPp; // Body // Change detection QData __req = false; // Logically a bool return __req; } void Vcounter::_ctor_var_reset() { VL_DEBUG_IF(VL_PRINTF(" Vcounter::_ctor_var_reset\n"); ); // Body clock = VL_RAND_RESET_I(1); reset = VL_RAND_RESET_I(1); enable = VL_RAND_RESET_I(1); counter_out = VL_RAND_RESET_I(32); __Vclklast__TOP__clock = VL_RAND_RESET_I(1); } void Vcounter::_configure_coverage(Vcounter__Syms* __restrict vlSymsp, bool first) { VL_DEBUG_IF(VL_PRINTF(" Vcounter::_configure_coverage\n");It looks better when it's compiled to x86 assembler !if (vlTOPp->reset) { __Vdly__counter_out = 0U; } else { if (vlTOPp->enable) { __Vdly__counter_out = ((IData)(1U) + vlTOPp->counter_out); } } vlTOPp->counter_out = __Vdly__counter_out;Which is pretty much a C++ version of my counter.