Check out my new 32 bit, 8 thread, 4 register/stack hybrid, pipelined verilog soft processor core:

http://opencores.org/project,hive

I spent quite a bit of time coding it and documenting it:

http://opencores.org/usercontent,doc,1371986749

Even if you don't care about my design, the paper might be interesting for general background.

Cheers!

(It took me all day to figure out SVN to upload the verilog, what a freaking pain! For non-group projects why can't we just upload a zip file or something?)

So, is there an assembler in the works
for this processor core -- How shall it
be programmed?

I skimmed through the documentation,
which implied the motivation to program
the processor in machine code, "without
the need for a compiler or even an assembler."

It might remain little more than a novelty until
and unless there is a software/firmware tool
chain of some kind.

That said, I think it would run FORTH extremely
well, and be suitable for hard real-time apps.
(And I hear that an assembler written in FORTH
is not too much work for someone who knows it.)

No assembler yet, not sure if / when something like that might happen, though if you look at the programming examples at the end of the paper or download the verilog you'll see the boot code is fairly "assembler-ish" as-is. The whole tool chain thing is kind of a turn-off to me as the OS / base platform is a constantly moving target, but it would almost certainly help with development as the boot code could be a simple boot loader. And having more things to change when the op-codes change would perhaps discourage me from changing the processor so often! (I'm hoping to simplify the immediates and separate the memory & IO spaces this week.)

I put the design out there not so much as a general purpose processor but for others who work in FPGAs to serialize complex & slow functionality, who need deterministic timing, and who find the current offerings overly complex (from an architectural and/or tool chain angle). As such it needs to be a good fit for the target logic, and I feel it also needs to be easy to conceptualize and program. Plus my particular implementation of indexed stacks might give others ideas for their processor designs.

If Hive remains obscure I'll be OK with that. I've looked into FORTH quite a bit in the past (and own several books on it) but discouragingly found the syntax difficult to read and the programming model overly simplistic (IMO) so there is almost zero chance of me taking it in that direction, but I remain open to the possibility of appreciating stack-based languages in general.

Eric,

I can help you or give you hints and tips writing a basic assembler.
I started recently writing one for my DSP-core.

Please let me know if this is of interest to you.

grtz

Simon

Hi Simon,

Thanks for your kind offer, I may take you up on it at some point.

I do have a spiffy Excel simulator of HIVE that took me a couple of weeks to write. It only simulates one core but that should be sufficient to thoroughly debug subroutines and such. It needs some way to conveniently get code into / out of it though.

Still working on the core, the operation ordering and encoding is significantly more unified now. I'm currently experimenting with 8 stacks rather than 4 as this seems to make complex coding easier for human brains to track by reducing the need for copy / move.

I just posted the latest design document for Hive v04.05.

http://opencores.org/project,hive

I can't connect to the SVN point so I can't update the verilog. Until then it's available here:
http://www.mediafire.com/download/g2nd401hhn4vf90/HIVE_2014-01-02_v04.05.zip

And here is the design document:
http://opencores.org/usercontent,doc,1389026037
http://www.mediafire.com/view/x7qci2cv4vyvdei/Hive_Design_2014-01-05.pdf

Hive now has 8 stacks and the opcodes have been modified somewhat. It's much cleaner and also has a double buffered UART. The design document has more programming examples. I'm working on an Excel VBA simulator for it.

hive unrelated: next time please use justified alignment for documentation text

Did you do any verification on your RTL?
Do you claim that your processor strongest point lies in the field of DSP? Maybe some code examples could demonstrate your ideas better than many words.

What part of FREE don't you understand?

Just posted v05.03 of Hive code and design document. There is enhanced interrupt support, and 32 bit indirect register set access. The verilog is a bit leaner and meaner (faster) than previous.

Just posted v06.01 of Hive
- Major changes in hive_main_mem.sv to support 16 & 32 bit aligned and unaligned access for literals and memory R/W.
- Main memory BRAM now a dual entity to provide separate addressing of high and low and to circumvent bootcode init issues.
- R/W immediate field offset is based on 16 bit access.

Quick link to the design document v06.01: http://www.mediafire.com/view/ghtn03wqe4a6k0z/Hive_Design_2014-07-15.pdf
Quick link to the SystemVerilog code v06.01: http://www.mediafire.com/download/9iloxic8535cdt7/HIVE_SV_2014-07-13_v06.01.zip

Quick link to the Excel simulator v06.01: http://www.mediafire.com/download/4vy7d202xu7fdbs/HIVE_SIM_2014-10-08.xls

With v08.06 there is now an interactive C++ simulation of the full core (all 8 threads) which runs at ~800kHz real time and really speeds up code development. It's a Win console app in the zip, source included. This is ~8 months of coding work! (I feel like I gestated and birthed a human baby!) The verification boot code was re-written via the sim, and there is an appendix in the doc that gives you a quick tour of the sim. Boot code is now *.mif based. Enjoy!

Impressive! That looks like it was a lot of work.

I'm curious, though ...

1. What was your purpose in building HIVE?
2. How do you see HIVE in relation to other processors? Do you see HIVE fitting into a particular niche? If so, what is its niche?
3. I didn't see any code for either assembler, compiler, or debugger. Have you worked on any of those? If so, what is their status? If not, do you have plans to do so?
4. According to the soft core IP inventory, the HIVE processor uses somewhere around 1800 LUTs. Is this still the correct figure? If not, how would you characterize its core usage and on what core did you measure it?

   If 1800 LUTs is your figure, then I congratulate you: I've been struggling to get the LUT count down on the Zip CPU that I've been working on personally, even though one of its explicit goals is to have a low LUT count.

I will also state that I find your copyright statement ... unusual. :)

Thanks!

Dan

Hello Dan,

I designed Hive for my own FPGA needs (I plan to use it in a digital Theremin) as a 32 processor that isn't nearly as complex as commercial offerings. IMO processors are overblown, which then makes toolsets and such mandatory. Outside of the simulator / code development environment there are no plans for assembler, compiler, etc. There aren't that many opcodes, and the mental model of the architecture is straightforward and manageable.

Hive currently consumes 2420 LEs of an Altera EP3C5E144C and runs at 194 MHz in that device. This is a tiny FPGA and it consumes a little less than 1/2 of it (though it gobbles up the BRAM).

"I will also state that I find your copyright statement ... unusual. :)"

My Engineering Ethics class in college went on and on about Frankenstein and Space Shuttle 0-ring whistleblowing and such, but never once mentioned the fact that most EEs do weapons / spy work. It's almost impossible not to get blood on your hands in my field, which distresses me greatly.

Hi Ericw,

I am embedded MCU based system designer.... yet, new to Verilog/VHDL for FPGA world. I am thinking about developing the Altera MAX 10 based FPGA board, tentatively to run at 80 MHz ...just for EDUCATIONAL PURPOSES in schools and university. I hope and will consider to introduce your HIVE Core into my FPGA board later and I hope to be able to get your support. My email sam_desd@yahoo.com.

RE: SAM