Hub Exec?

David Betz

I've seen a number of comments fly past about people thinking about adding hub exec to the P1 Verilog code. Has anyone actually started this? How far have you gotten? I've been thinking that hub exec is really the first step I need to take when tackling CMM since I first need to be able to fetch instructions from hub memory before trying to decode byte streams rather than PASM longs. Is anyone actively working on hub exec for P1?

Cluso99

I have been thinking and am just now ready to begin. Firstly I m going to use it to run from extended cog because I can get the first part of it running easier than ful blown hubexec.
I have cogs > 2KB so I cn move some code above 2KB to test it. I can code the jmpret wc as just a long so I can use proptool to compile this for me. I should b coding this tomorrow.
So yes, I am working on it.
1) Increase pc to > 9 bits. Probably choose 16/18 bits.
2) Change JMPRET to calculate both D & S operands as relative to pc if WC set.
3) Initially addresses > 2KB will be in extended cog.
Once working I can then proceed to making addresses > 4KB? in hub. But JMPRET WC cannot have D in hub.

David Betz

Thanks for the update. I knew from another thread that you were working on a Super COG. I guess I'm thinking of attacking this from the other end, allowing hub memory to be used during instruction fetch. Maybe we can meet in the middle somewhere! However, I imagine you'll be way ahead of me because I have very little time to work on this.

pik33

I am rather thinking of executing directly from sram/sdram using extended portb (now I have 64bit output via outb and dirb and 32bit input via inb) to access it directly from the cog. Cog's PC have to stay on inb while new, extended 32-bit pc increase and set dirb to fetch a new opcode from external ram.

David Betz

pik33 wrote: »

I am rather thinking of executing directly from sram/sdram using extended portb (now I have 64bit output via outb and dirb and 32bit input via inb) to access it directly from the cog. Cog's PC have to stay on inb while new, extended 32-bit pc increase and set dirb to fetch a new opcode from external ram.

Sounds interesting. I guess you'll add an SDRAM controller to the Verilog? Will you be adding caches as well?

pik33

I have an sdram controller ripped from a terasic demo (free to use with their DE boards) and some other verilog components intended to use with Nios2. After I finish what I started (a prop-de2-115 sound player) , I will try to connect and use them with the Propeller. I didn't think about the cache now.

Cluso99

David,
I see the method I am using is just a stepping stone to getting hubexec working where I can test each step quicker. There is a lot to learn about verilog along the way, as well as properly understanding the actual P1 code too. I can get a program running using the upper cog ram without the details of accessing hub. Once this is established, together with the extra instructions required, then I can add in the fetch from hub.

pik33,
That's an interesting twist. I will be interested to see how it works out.

David Betz

Cluso99 wrote: »

David,
I see the method I am using is just a stepping stone to getting hubexec working where I can test each step quicker. There is a lot to learn about verilog along the way, as well as properly understanding the actual P1 code too. I can get a program running using the upper cog ram without the details of accessing hub. Once this is established, together with the extra instructions required, then I can add in the fetch from hub.

pik33,
That's an interesting twist. I will be interested to see how it works out.

I figure there is already code in the P1 to handle reading and writing hub memory. Actually, all I'll need to do is read. The main trick is to stall the processor when I need to fetch an instruction.