Let's Design and Build a (mostly) Digital Theremin!

Posted: 8/8/2017 6:09:32 PM
dewster

From: Northern NJ, USA

Joined: 2/17/2012

Thought you might like to see the sim so far:

The listing for thread 7 is above, at lower left is the register set (with only the basic core registers shown, none of the Theremin registers), at lower center is the stacks status for thread 7, and at lower right is some info / sim status.  I'll probably swap the register and info views to make room to view more registers on the lower right with the command line on the lower left.

In the listing display, the "BYT", "LIT", and "LINE" columns are new, they show how many bytes are in the opcode, whether the opcode is a literal or not, and what line in the sourcecode the opcode came from (extremely useful).  Note the explicitly variable lengths in the opcode column now.

The command line code isn't implemented yet (only doing single key stuff at the moment to prove the core and display) and I'm not sure if there will be any screens other than this one because I want to keep it really simple.  For the current single key stuff (which will likely change somewhat) the number keys select the thread to display, the 'c' key does one clock, the spacebar does 8 clocks, the 'h', 'u', and 'i' keys pick the display radix, and the 'q' key quits the sim.  I need ways to interact with the UART FIFOs, GPIO, and SPI; load a different *.hal file; issue core clear and external interrupts; and page/scroll through the memory listing display without execution.  (I wish IBM had started the function key numbering at F0 rather than F1...)

The new sim snags pertinent state info for each thread when it crosses from stage 7 to stage 0 in the pipeline.  This way the state info remains stable throughout an 8 clock thread cycle for display purposes.  In the old sim the displayed state was dependent on the stage you were viewing, which was realistic, but cumbersome and a little confusing - after changing the thread view I usually had to do several single clocks to get past stage 5 where the fetch happens in order to see the next state.

===========

[EDIT] Wow, this thread got ~500 views in 24 hours.  Kind of hard to believe there are that many people in the world, much less visit here, with the intersecting interests of Theremins and soft processors.  Bots?  Web page scraping?

Posted: 8/11/2017 3:27:45 PM
dewster

From: Northern NJ, USA

Joined: 2/17/2012

Not a lot of visual change, but it all of the essential features are implemented and seem to be working:

I swapped the register and info views to make room to view more registers on the lower right with the command line on the lower left.  The Theremin registers aren't here, I will add them later, and may make them an executable command line option so that others who want to use the Hive core won't be bothered by them.

Doing 800,000 verification cycles (as seen on the command line at the lower left) takes 94 seconds of real time on my PC (AMD Athlon II X2 250, XP SP3). 800,000 cy / 94 sec = 8.5 kHz, and this is the per thread rate.  The core clock rate is 8 times this, or 68 kHz.  The FPGA hardware runs over 180 MHz, so the C++ sim is is a couple of thousand times slower than the hardware, which really isn't too shabby.  

Ten times the cycles (8,000,000) in the old sim take 81 seconds, so the new sim is roughly 12x slower than the old.  I haven't done any profiling, but I imagine the slowdown is due to data moving through the pipelines in a more realistic manner, with double the representation for clocking (asynchronous & registered).  Whatever, it's going to be easier to maintain the new sim code, and it's likely fast enough for what I need to do.  Sort of ironic that the things you do to speed up the hardware implementation slow down the software representation.

One nifty feature I added to the sim last night is a cleared screen which shows the verbose results of the HAL assembly process to memory, with a "hit any key" pause to read them.  Today I added a MIF file write command which kicks out the FPGA config files. Together these features largely obviate the need for a stand-alone assembler.

(Will be going on vacation for a couple of weeks starting Sunday, so light to no posting in the interim.)

Posted: 8/11/2017 7:03:41 PM
ILYA

From: Theremin Motherland

Joined: 11/13/2005

Have a good vacation Dewster! Dont forget about TW!

Posted: 8/11/2017 9:04:56 PM
oldtemecula

From: 60 Miles North of San Diego, CA

Joined: 10/1/2014

Hey dew,

Coding is not like riding a bike or the nasty, walk away for two weeks and it takes precious time to get the brain synapses fired up again. Have fun and we will not worry if you found paradise and do not come back. surprised

Christopher

Posted: 8/11/2017 10:38:27 PM
dewster

From: Northern NJ, USA

Joined: 2/17/2012

"Have a good vacation Dewster! Dont forget about TW!" - ILYA

Thanks ILYA, I won't forget!

"Coding is not like riding a bike or the nasty, walk away for two weeks and it takes precious time to get the brain synapses fired up again. Have fun and we will not worry if you found paradise and do not come back." - Christopher

That's the truth!  The main reason to code as simply and directly as possible.  I had this bad feeling when coding the initial sim (as an exercise in OOP) that I should have instead been doing so with as much fidelity to the hardware as possible.  Ah well, a rewrite was probably called for at this point anyway.  Leaving every possible option out and combining / simplifying those that remained is something you can only do more or less correctly in a later pass.  At the time of the initial sim I didn't know that I'd be implementing an assembly language down the road (I did everything I could to avoid it, but it makes too much sense in the developmental flow of things) so there were a bunch of editing options I was able to remove this pass.

You must be logged in to post a reply. Please log in or register for a new account.