AnyCPU
http://anycpu.org/forum/

g-core
http://anycpu.org/forum/viewtopic.php?f=23&t=674		 Page 2 of 3
Author:  BigEd [ Sat Jan 18, 2020 9:19 am ]
Post subject:  Re: g-core
Hmm, I count 14 bits in the Vax format: 8 mantissa and 6 exponent. It's clever, and it's new to me. I did know the ARM's system, which is 8+4 bits. https://alisdair.mcdiarmid.org/arm-imme ... -encoding/
Author:  joanlluch [ Sat Jan 18, 2020 9:12 pm ]
Post subject:  Re: g-core
I think Rob may refer to the VAX 6 bits “literal” format, that was used to quickly represent common floating point numbers without using the “immediate” mode. (The table of representable 6 bit “literal” floating point values is in page 36 of the VAX Architecture Reference Manual)
Author:  BigEd [ Sat Jan 18, 2020 9:14 pm ]
Post subject:  Re: g-core
Ah, a small table - thanks!
Author:  robfinch [ Mon Jan 20, 2020 5:07 am ]
Post subject:  Re: g-core
Yes, I was referring to the six bit "literal" format. I think of literal and immediate as synonyms.

I've managed to resolve the issue a little further. In the FPGA the core is not working correctly because a store instruction is improperly being sent to an ALU. The core isn’t issuing instructions correctly. The ALU doesn’t know what to do with the store so it just outputs ‘deaddead’. Things work fine in simulation. I’m trying to figure out how I can track down this issue given only a small number of signals to probe with. The probes actually end up on the critical timing path. It would be nice to dump the entire queue plus issue signals but it's hundreds of signals. I may end up building some sort of probing facility where the processor can be single stepped.
I've been experimenting with different queue sizes and test programs to try an trip things up in simulation. It's got to be a logic error of some sort.
Author:  robfinch [ Wed Jan 22, 2020 7:23 am ]
Post subject:  Re: g-core
Found out the memory operation size was decoded incorrectly, then found out it wasn’t actually used anywhere.

Added 8-bit float immediate constants to several FP instructions where there was an extra bit available to specify the constant.
Still, debugging the core in the FPGA, it's slow going because of 3hr system builds.
Author:  robfinch [ Fri Jan 24, 2020 5:09 am ]
Post subject:  Re: g-core
Worked on memory management unit today. Memory management includes both segmentation and paging. There are sixty-four segment registers. The segment register in use is selected by the upper six bits of the virtual address.

Decided to give the ole superscalar projects a lower priority. I've been working on them for about four years or so, and haven't gotten them much past clearing the screen. It's just taking too much time debugging. I've had better luck with classic pipelined risc architectures. Switched back to working on DSD9, a project from about four years ago.
Author:  robfinch [ Thu Mar 19, 2020 6:32 am ]
Post subject:  Re: g-core
I spent some time trying to find a “premade” core to use for the system as I’m having limited luck getting a processing core to work lately. Not finding anything I started working on several different cores, including some from the past.
Put some more work into the g_core. It wasn’t running in the FPGA but seemed to be running in simulation. It turns out there seems to be issues with the I$ output. At one point I thought the byte order was reversed but it turned out to be a cache line not updated properly. Just waiting now for the system to build, this is a 45 minute process.
Author:  robfinch [ Mon Mar 23, 2020 2:41 am ]
Post subject:  Re: g-core
Experimenting with g-core tonight. Running in the FPGA it executes a handful of instructions then stops when it encounters what looks like a break instruction in the middle of an instruction. It runs far enough to display ‘AA’ on the leds. The issue is the program counter isn’t correct so it’s pointing into the middle of an instruction. Hence I’ve been taking a look at the program counter logic. The program counter is currently incrementing by the length of one or two instructions depending on how many instructions queue. I think this is not correct. It should always increment by the length of two instructions since two instructions are being fetched. I tried switching it around and the program doesn’t work any longer in simulation.
Incrementing by one instruction length, which is the current process, doesn’t work 100% right either. Sometimes a duplicate instruction ends up in the fetch / decode buffers. When incrementing by two only, sometimes there’s an empty instruction in the fetch / decode buffers. It’s seems one just can’t win.
I’ve managed to modify the core to increment by two instructions in the fetch stage. It seems to run in sim, but the real test will be running in an FPGA.
Author:  robfinch [ Tue Mar 24, 2020 8:12 am ]
Post subject:  Re: g-core
Completely, re-wrote the fetch buffer and decode buffer portion of the core doubling up on the number of decode buffers so there is a right and left decode buffer. The core now loads a decode buffer once it’s empty rather than checking how many instructions queued. Instruction are queued out of one of the decode buffers as empty slots become available in the queue. The result is the processor is slightly faster now because it doesn’t operate in spurts waiting for four empty queue slots. It seems to work in simulation, it was run until the constant ‘2d’ appears on the LEDs in sim. But when running in the FPGA it now hangs at ‘xxx51d’ instead of ‘xxx51e’ which is where it was hanging. ‘AA’ no longer appears on the LEDs.
Author:  robfinch [ Mon Apr 06, 2020 3:17 am ]
Post subject:  Re: g-core
It turns out the xxx51d is a valid address so pc logic is operating correctly. It hangs on a memory operation to an invalid address. It looks like results from one instruction are not being incorporated correctly in the next one when calculating the memory address after a looping branch takes place. I'm not sure if it's skipping over an instruction or not.

Anyway, worked on the g-core front end. There seems to be something amiss in the during the fetch of instructions so I’m modifying the front-end to use a fetch buffer pair from the RisC-16. Hopefully the re-write will either resolve the issue or high-lite it.
Author:  robfinch [ Wed Apr 08, 2020 3:59 am ]
Post subject:  Re: g-core
Still working on the fetch phase of g-core. I didn't find the issue. I think I got all the bugs worked out of the new front-end. At least it seems to run three different test programs successfully in simulation. I ran the Fibonnaci, Sieve of E. and part of the boot rom. With a little bit more work it may be possible to make the front-end generic so it can be plugged into a different core.
Author:  robfinch [ Sun Apr 12, 2020 3:48 am ]
Post subject:  Re: g-core
Worked on g-core some more. Playing around with the core, I switched from non-blocking to blocking assignments almost everywhere and lo-and-behold the core hung when simulated in almost the same manner it is in the FPGA. So, I fixed the hang for simulation and rebuilt the system.

There’s an error in the following code that I found by inspection.
Code:
`ADD_RI22,`ADD_RI35:   o = a + imm;
`SUB_RI22,`SUB_RI35:   o = a + imm;

I must have been block copying lines and forgot to change the sign. Fixing this error led me to splitting up the subtract opcode group into subtract register and subtract-from immediate. It’s handy to be able to subtract from an immediate and there’s already a subtract immediate via the add immediate instruction with the constant negated.
Code:
`ADD_RI22,`ADD_RI35:   o = a + imm;
`SUBF_RI22,`SUBF_RI35:   o = imm - a;

I picked up the subtract from trick by studying the PowerPC instruction set.
Author:  robfinch [ Tue Apr 14, 2020 3:08 am ]
Post subject:  Re: g-core
Split up the issue logic for the alu and fpu. The issue logic for both alus used to be in a single module which had a single instance. It has now been recoded to use the same module twice (once for each alu) with the module supporting only a single alus issue logic. The same was done for the fpu and agen issue logic.
Some minor tweaks in the source code. After the latest build the FPGA results in a hung run because of a bad address. The bad address comes from an invalid alu instruction. Where this comes from is a bit of a mystery yet. On inspection of the code it was found that a multi-cycle alu operation might set the alu output valid bit even when there was no longer an alu operation taking place. This would be bad because it would put false alu results on the common data bus. However, current the test programs don’t use multi-cycle alu ops so this shouldn’t be the issue causing a hang. The solution was to nop out the alu instruction once the operation is complete.
Author:  robfinch [ Wed Apr 15, 2020 5:31 am ]
Post subject:  Re: g-core
Still no luck getting g-core working in an FPGA. There must be some subtle difference between simulation and synthesis.

Been playing with posit numbers. Got fpToPosit and positToFp conversions working. I am working on a posit adder/subtracter now.
Author:  robfinch [ Thu Apr 16, 2020 4:46 am ]
Post subject:  Re: g-core
Got another posit converter working: int to posit. Addsub results are still garbage.
Page 2 of 3 All times are UTC
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/