Hi Fred,
Hive is coded in verilog in a modular way. Separate *.v files hold the code for various pieces ("modules") and they are pulled together and wired in a hierarchical manner as sub components, which are themselves pulled together wired up as the Hive core at the top level module ("hive_core.v").
To use it, one would write an even higher level module that pulls in ("instantiates") the top level module along with other logic and wire them up. This would likely be written in verilog (mixed HDL projects are supported by FPGA vendor tools but I've never tried it) or via the proprietary schematic capture method in the given tool.
Here is the top level entity for my Cyclone 4 demo board:
module ep4ce6e22c8_demo_board
#(
parameter integer LED_W = 4
)
(
// clocks & resets
input wire clk_50m_i, // clock
input wire rstn_i, // async. reset, active low
//
output wire [LED_W-1:0] led_o // LEDs, active low
);
/*
----------------------
-- internal signals --
----------------------
*/
wire [31:0] io_o;
wire clk_pll;
pll pll_inst (
.inclk0 ( clk_50m_i ),
.c0 ( clk_pll )
);
hive_core hive_core_inst
(
.clk_i ( clk_pll ),
.rst_i ( ~rstn_i ),
.xsr_i ( ), // unused
.io_i ( ), // unused
.io_o ( io_o )
);
// the LEDs are active low
assign led_o = ~io_o[3:0];
endmodule
You can see that the Hive core has a rather trivial port interface: clock, reset, interrupts, and GPIO (the UART port isn't shown here).
For this uber entity you would specify pinout in the vendor tool, as well as any timing constraints for the pins and internal logic. The tool facilitates this to some degree, but you can specify these things with text files as well, and I generally find this to be the easiest route. For slow I/O like LED outputs, button and encoder inputs, etc. the pin timing can be set to don't care, and the internal timing is largely constrained by telling the tool the input clock frequency you will be supplying (likely through and internal PLL to multiply it up as it is in my above example).
Once that is done you need to program Hive. The boot code is in a file ("boot_code.v") which initializes main memory. You would edit this file and rebuild the design, then reprogram the FPGA configuration memory. At power cycle (or pressing the "config" button on the demo board) the new load is pumped into the FPGA and you're in business. Boot code is actually written in verilog, and uses some of the language features to make it fairly readable.
For anything other than trivial programs, the Excel simulator is probably the place to develop subroutines and such, but it's a little clunky and kind of slow. I'm still working on porting the Excel output to a text file, which could then be uploaded to Hive running a boot loader / tiny monitor of sorts. Some kind of serial memory would be necessary (they can be had for almost nothing) wired to the demo board. Programming support is something of a missing link for larger projects.
In terms of the things you might bolt onto the Hive core, there is free code out there for a lot of functionality, but who knows what the quality may be like. At freecores they came up with the "wishbone" standard so as to standardize a register set interface between code and processor. If your processor core and the additional functionality are both wishbone compliant you can theoretically join them together easily. I have my own register primitive that the internal register set is constructed with, and prefer to keep this kind of logic in one conceptual spot rather than spattered around the design. So with Hive you would probably end up writing or at least heavily adapting code for extensions / peripherals.
=============
I've been bumping up against the inherent limitations in verilog (no multi-dimensional ports, no packages) so today I'm working on porting Hive to SystemVerilog. SV is confusingly named, it's actually an updated version of verilog, with the verilog name going by the wayside. SV is touted (and used) more as a verification language, but synthesis support is definitely there and a definitely an improvement over verilog. Surprisingly there is NO support for SV in the Xilinx XST tool! Altera Quartus seems to support SV pretty well and has done so for quite some time.
Eric