...
Which is pretty much a C++ version of my counter.
Yes, the core code looks quite good really.
You could code an Up/Dn/Rst/En/Load/Add Counter/Adder, & check that still compiles to 32b operations ? That's closer to a MCU Program Counter.
A smart pin has 2 x 32b counters plus set & capture latches, & compare, so it should simulate quite well, and that's where a Verilog-derived Sim version will truly shine.
I might try and make that a more general counter if I find a free moment.
I suspect that it would still compile to 32 bit ops for my 32 bit register. I have no idea what happens for odd sized registers like 5 bits or 327 bits !
OK, the Verilator compilation of Verilog into C++ goes pretty easily.
Heater,
Thanks for posting a great verilator tutorial. I found this thread last night and I already have the P1V running. It wasn't too hard to add wavefrom generation either. It's really cool to be able to plot any of the internal signals. And it's so fast!
The tutorial is on page 1 of this thread. The >> of my quote provides a link to the post.
Check my github for a proof of concept P1V simulator. There's currently no way to program it. I intend to do this by pre-loading the ram. Another clever way to do this would be emulating an EEPROM in verilog. That should be as accurate as you can get. The RAM/ROM contents can be changed without recompiling the simulator. They are loaded from the hex files when the simulator starts.
Not had a chance to play with this, also too new to it, but a question.... If this entirely simulates the P1, and given that according to what I have read about the load source order, the Prop can detect and load from a PC, would it be possible to set up at least in linux, a ttyxxx link such as BST uses and the simulated P31/30 pins of the simulator? I don't know enough to know if this is a reasonable possibility, but maybe it could be made to work. Then again, how to get the external hardware into the mix?
Many things are possible... I'm not sure what is involved in creating a virtual serial port. There could be synchronization issues if the virtual Propeller runs at a significantly different speed. It would also be possible to make a special interface with propman for loading the simulator. I think the virtual EEPROM is the most versatile. It's easy to load memory in verilog. By having the entire design in verilog, it could also be used with other verilog simulators or real FPGAs.
PCs are not well suited for realtime processing or IO. The simulator could run on a BeagleBone or Raspberry Pi. They have reasonably fast IO. I would expect the simulated clock rate to vary depending on what is running on the virtual Propeller. Also expect the simulator to pause while the CPU does other things.
Many things are possible... I'm not sure what is involved in creating a virtual serial port. There could be synchronization issues if the virtual Propeller runs at a significantly different speed.
Certainly it is unlikely to be able to match real-time, so the serial source needs to be Baud-rate variable.
It's also the easiest to explain.
What is the speed penalty of adding Virtual EEPROM ? I guess it's a one-off, and some of the booter timeouts can be reduced/removed, and probably even EE loader can be clock-bumped, to need less P1 Cycles... (padding NOPs removed)
A quick check gave these numbers on EE loading :
Rough Calc 3*9+(1+32768)*9 = 294948 Clock, Actual Counter measure says 294950 (+2)
Avg Freq is 253.932kHz on SCL (for 400kHz MAX target i2c )
294948*(1/253.932k) = ~1.161 seconds
Indicated SysCLKs per SCL is ~ 40
SaucySoliton, I looked at your GitHub site, but I don't see the C++ code that you generated. Can you tell me how to download it? I'd like to try running it.
Actually installing things like Verilator is a pain on Windows. I just did it on a new Win 10 laptop:
1. Ensure you are running Win 10. Which you may not actually want to be.
2. Install the Linux Subsystem for Windows. Which might take some googling as even the instructions from Microsoft don't work.
3. Figure out how to get LSW font size big enough to read.
4. Install git, vim, flex, bison, autoconf, make into LSW.
5. Follow the build/install instructions for Verilator: https://www.veripool.org/projects/verilator/wiki/Installing
Then we can get on with the problem of Verilating P1V....
The attached tarball contains the content of the P832A_Verilator directory after running the build script. There is the transpiled C++ in the obj_dir directory and also a binary executable for Linux, "simulator".
Vtop_veri.mk:59: /usr/local/share/verilator/include/verilated.mk: No such file or directory
Apparently I need verilated.mk.
EDIT: I looked at main.cpp and it looks like it runs one million loops and then prints DONE and exits. How long does it take the program to run. I did a WC on the object directory and got about 52,000 lines of code. For comparison, spinsim contains 13,000 lines of C code. However, that doesn't include logic for the counters.
I'm able to build the executable under Cygwin now, but when I run it I get the following error:
%Error: ../HDL/rom_f000_ffff_scrambled.hex:0: $readmem file not found
So now I need the ROM file. Could someone please post that?
0.68 seconds for one million cycles would be 54.4 seconds for 80 million cycles, which corresponds to 1/54th real time.
BTW, I simulate the I2C interface to the EEPROM in spinsim. We would just have to tie into pins 28 and 29 and we could load the emulator from a simulated EEPROM. My EEPROM simulator gets its data from a file name eeprom.dat. I also have a simulated serial interface, which would allow interfacing to pins 30 and 31.
Initially, it would be good just to determine where the 32 I/O pins are located in the emulator, and print out the values whenever they change.
I got the ROM files from yeti, and I was able to run the emulator. It took a little over 1 second to run on my machine under Cygwin. So the next step is to figure out how to access the pin data.
I updated the repository with an example for printing pin data to the console. I'm including the verilator output files just for you, Dave. Don't forget that you can download repositories as a zip.
You should have noticed the trace.vcd file that is created. It is very large because it includes all the internal signals as well. For example, you can plot the program counter "p." I use gtkwave to view it.
Verilog models are available from EEPROM vendors. I found some from Microchip and ST. Of course, it would be nice to find one licensed as GPL.
Saving the waveform data takes more time than running the simulation.
trace off real 0m0.291s user 0m0.289s sys 0m0.001s
trace 1/8 real 0m0.860s user 0m0.849s sys 0m0.007s
trace 1/1 real 0m2.401s user 0m2.356s sys 0m0.036s
Comments
Yes, the core code looks quite good really.
You could code an Up/Dn/Rst/En/Load/Add Counter/Adder, & check that still compiles to 32b operations ? That's closer to a MCU Program Counter.
A smart pin has 2 x 32b counters plus set & capture latches, & compare, so it should simulate quite well, and that's where a Verilog-derived Sim version will truly shine.
I suspect that it would still compile to 32 bit ops for my 32 bit register. I have no idea what happens for odd sized registers like 5 bits or 327 bits !
Lucky there are no 327 bit counters in P2
Yes. A lot of that Pandora's Box opening goes on around here.
Thanks for chivying me along to look into the Verilator. That is a box I have been meaning to open for some time.
Heater,
Thanks for posting a great verilator tutorial. I found this thread last night and I already have the P1V running. It wasn't too hard to add wavefrom generation either. It's really cool to be able to plot any of the internal signals. And it's so fast!
Got a link?
Check my github for a proof of concept P1V simulator. There's currently no way to program it. I intend to do this by pre-loading the ram. Another clever way to do this would be emulating an EEPROM in verilog. That should be as accurate as you can get.
PCs are not well suited for realtime processing or IO. The simulator could run on a BeagleBone or Raspberry Pi. They have reasonably fast IO. I would expect the simulated clock rate to vary depending on what is running on the virtual Propeller. Also expect the simulator to pause while the CPU does other things.
It's also the easiest to explain.
What is the speed penalty of adding Virtual EEPROM ? I guess it's a one-off, and some of the booter timeouts can be reduced/removed, and probably even EE loader can be clock-bumped, to need less P1 Cycles... (padding NOPs removed)
A quick check gave these numbers on EE loading :
Rough Calc 3*9+(1+32768)*9 = 294948 Clock, Actual Counter measure says 294950 (+2)
Avg Freq is 253.932kHz on SCL (for 400kHz MAX target i2c )
294948*(1/253.932k) = ~1.161 seconds
Indicated SysCLKs per SCL is ~ 40
What, you took my little Verilator example and ran with it, now you have a fully working, cycle accurate P1 simulation in C? Brilliant, well done!
I have been traveling for 3 months so I pretty much forgot about the Verilator P1 idea.
Hope what you are doing finds its way upstream.
Best to install the Verilator and build it yourself.
Installing Verilator, cloning a Git repo and starting the right script is an adventure these days?
Mooooooooom!!!
I seem to have woken up in a weird alternate reality!
;-)
...it is simple...
Really...
1. Ensure you are running Win 10. Which you may not actually want to be.
2. Install the Linux Subsystem for Windows. Which might take some googling as even the instructions from Microsoft don't work.
3. Figure out how to get LSW font size big enough to read.
4. Install git, vim, flex, bison, autoconf, make into LSW.
5. Follow the build/install instructions for Verilator: https://www.veripool.org/projects/verilator/wiki/Installing
Then we can get on with the problem of Verilating P1V....
The attached tarball contains the content of the P832A_Verilator directory after running the build script. There is the transpiled C++ in the obj_dir directory and also a binary executable for Linux, "simulator".
I can run ./simulator which just prints "Done!".
I have no idea where to go with this....
Here is P1V verilog source transpiled to C++
EDIT: I looked at main.cpp and it looks like it runs one million loops and then prints DONE and exits. How long does it take the program to run. I did a WC on the object directory and got about 52,000 lines of code. For comparison, spinsim contains 13,000 lines of C code. However, that doesn't include logic for the counters.
Attached are the verilator includes in case that helps.
0.68 seconds for one million cycles would be 54.4 seconds for 80 million cycles, which corresponds to 1/54th real time.
BTW, I simulate the I2C interface to the EEPROM in spinsim. We would just have to tie into pins 28 and 29 and we could load the emulator from a simulated EEPROM. My EEPROM simulator gets its data from a file name eeprom.dat. I also have a simulated serial interface, which would allow interfacing to pins 30 and 31.
Initially, it would be good just to determine where the 32 I/O pins are located in the emulator, and print out the values whenever they change.
...so later a "git pull" in there should be doable too...
—▶ http://yeti.freeshell.org/20170702-P1V-not-cleaned-after-build/
53MBytes is way too fat to be attached here.
I'll delay cleaning up that dir for a while.
You should have noticed the trace.vcd file that is created. It is very large because it includes all the internal signals as well. For example, you can plot the program counter "p." I use gtkwave to view it.
Verilog models are available from EEPROM vendors. I found some from Microchip and ST. Of course, it would be nice to find one licensed as GPL.
Saving the waveform data takes more time than running the simulation.
trace off real 0m0.291s user 0m0.289s sys 0m0.001s
trace 1/8 real 0m0.860s user 0m0.849s sys 0m0.007s
trace 1/1 real 0m2.401s user 0m2.356s sys 0m0.036s