RTL Engineering Superb! Not much else to say except "thanks". I can't wait for your next vids. Please don't spare us any gory details nor HDL snippets, even if the vids are slightly longer. ;) Finally some videos on YT that go into a lot more detail on the 90s era consoles / processors. You've inspired me to look at implementing the GTE instructions for the PS1 again today. I'll make a cheat sheet first, as most of the registers have a specific storage purpose. At least it's all fixed-point on the PS1 - none of this scary floating-point stuff. hehe
Thanks! I'm glad you are enjoying them. Fixed point should be slightly easier to do. Let me know if you want some help with it - I have a fixed-point arithmetic class in C++ that I created while taking a VLSI course (originally from a VHDL implementation), which implements each operation in a line or two of code (for arbitrary fixed-point format). If you connect it to a R3000a model in HDL, you should be able to simulate it, and run the actual boot ROM / game ROM (it would be very slow, but much easier to debug than using signal tap).
Great, thanks. ;) I'll definitely be picking your brain on this later. I'm guessing / hoping that a fair few instructions on the GTE can be done directly by shifting the first (and sometimes after), and maybe sign-extending some stuff as well? Along with the excellent info from no$cash on the PS1, I've just been using this PDF to figure out what I need to start implementing for the GTE... hitmen.c02.at/files/docs/psx/psx.pdf And in the last hour or two, I've managed to make sense of the basics, and wrote this... (hey, it's a start, right? :p) pastebin.com/VQnr1zTd Now, I realise that you would probably be implementing things in an entirely different way, and there WILL be some mistakes in what I'm attempting, but I think it will work OK, even if I initially need to use twice the normal clock freq to step through all of the instruction states. If nothing else, it's been fun learning more about the GTE, as I've wanted to write some Verilog for many years that will actually do some useful matrix maths stuff, and spit out some decent polygons. Just to write a basic 3D renderer on real hardware would be awesome. ;) Is there anything really glaring that you would do differently in my code btw? I know that I could just pick groups of bits from the regs directly while doing each instruction, but it is nice to have the wire defines too. I also realise that I will have to make sure I properly register all of the results, but I think it's workable like this?
I just realised that the "wire" defines might be fine for grabbing the bits from the GTE regs, but for writing back to the regs, I should just change all of the "wires" to actual defines or parameters. The only thing then is that the "wires" make it easier to tell how many bits should be grabbed from each reg, for each value. hmm. the first of many things to ponder... lol
I'm not as familiar with the GTE as I am the RSP, however, I would take a step back from writing the actual HDL, and work on a block diagram, to figure out what all needs to be in it. I believe it also used the general purpose register file format, so that adds additional complexity, where you need to have the CPU be able to read / write to any of the 32 registers. You should also think about adding constants / parameters for the module, one of them being the bitwidth of 32 (I know the actual implementation was 32-bits, however, it wouldn't hurt to provide an N-bit interface so that if someone wanted to, they could tack it onto a 64-bit processor). Besides, it's always good programming practice to try not to hard code things directly in-line. I'm not sure if it's a verilog quirk, but you are probably better off splitting the design up into a clocked block for the registers, and a combinational block. I would always run into un-expected behavior when I wrote FSMs with everything guarded by the clock. So in VHDL, there is no register type. Instead we would create two copies of the signal / wire being var and var_c. Where on the clock edge, all we do is var
Thanks for the comprehensive reply. I'll have to absorb this info for a while. I did see that GTE.txt source before, but completely forgot until you linked to it. :p I'm decoding the top 8-bits of the opcode for the 22 or so GTE instructions now. The basic sub-steps of each instruction don't look too bad on the face of it, but the problem is trying to comprehend things like the C / C++ sources in MAME, where they use a lot of macros and inline code for doing clamping and saturation etc. The capstone link is great btw. I saw a few of those white papers, where various Uni students had looked at implementing the SNES and other machines, and did read the PSX one before, but I didn't realise they'd actually shared the sources for it. :o That github you posted is superb, as they did manage to implement most of the GTE stuff by the looks of it. haha - just re-read this old line in their PDF... "If you are continuing from where we left off, synthesize the project, upload to the board, open up no$psx, and start back tracing. We are in the middle of the BIOS and entering an (invalid?) loop right before the white screen comes on in the BIOS animation." I had EXACTLY the same issue when I was trying to get the PS1 BIOS to boot further on the DE1. lol With the help of another few comments from no$cash, and a lot of stepping through the code under MAME, I finally found the BIOS routine I had to NOP out. I believe it's something to do with some kernel debugging output that it gets stuck on? I'm not entirely sure what it does. The routine for initialising the SPU then follows that, which of course haven't implemented yet, so I had to add another NOP for that. For the "NOPs", I just added this, which patches the BIOS code as it loads the main kernel code into RAM by the CPU at power-up... wire [15:0] SDRAM_DIN = (BYTE_ADDR==32'h00002834) ? 16'h00 : // Shove in a NOP! (for the Kernel IO redirect thing). (BYTE_ADDR==32'h0005418C) ? 16'h00 : // Shove in a NOP! (for the first part of the SPU setup routine) (state==16) ? WRITE_DATA_BACKUP[15:0] : WRITE_DATA_BACKUP[31:16]; And now I just noticed that I was technically only using an 8-bit value for the 16-bit wide bus. Oh well, it worked. lol That's great info though. I see that capstone PSX project is in SystemVerilog, but it's not hugely different. I can now follow their GTE code, and see if I can implement it in my own crusty Verilog style. hehe Regards, Ash.
@@RTLEngineering There's almost no mention of the 4300. I've seen quite a few TH-cam videos that take some time to get to the point, but there are no details of the "VR4300 Primer" until about the 13:00 mark. It's a good video for newbs and non-engineers, but the title doesn't really match the content. How about "Primer on CPUs and the VR4300"
I think I understand your confusion. This video was presented as an intro lecture to the VR4300 (there were going to be more videos following it), which required some background knowledge / refreshers (i.e. primer to the VR4300 not of the VR4300). It would not be accurate to say it was a primer on CPUs - digital logic if anything, but insufficient to really be called a primer on/to digital logic. Anyway, I made this video several years ago and would definitely approach it in a different way now.
The rest of the intro was: "..., as I was working on it, I realized that it is worth a series on its own. I also realized that there are some brief miscellaneous topics I would like to cover before diving into the VR4300. " In other words... I was going to make a single video on the VR4300 but that video ended up being too long, and at the time I was thinking about it from an accessibility perspective (in the mindset of a lecture rather than a technical report or to-the-point short). The video would therefore start off general and then go into the VR4300, which it did. That's the typical format that would be expected of an undergraduate university lecture in computer engineering, albeit with expedited background. Anyway, I am sorry if you misunderstood the video title. However, I believe it correctly encapsulates the content within. If you are still unsatisfied, then I would encourage you to create your own channel covering such topics - that's why I created mine.
RTL Engineering
Superb!
Not much else to say except "thanks".
I can't wait for your next vids.
Please don't spare us any gory details nor HDL snippets, even if the vids are slightly longer. ;)
Finally some videos on YT that go into a lot more detail on the 90s era consoles / processors.
You've inspired me to look at implementing the GTE instructions for the PS1 again today.
I'll make a cheat sheet first, as most of the registers have a specific storage purpose.
At least it's all fixed-point on the PS1 - none of this scary floating-point stuff. hehe
Thanks! I'm glad you are enjoying them.
Fixed point should be slightly easier to do. Let me know if you want some help with it - I have a fixed-point arithmetic class in C++ that I created while taking a VLSI course (originally from a VHDL implementation), which implements each operation in a line or two of code (for arbitrary fixed-point format).
If you connect it to a R3000a model in HDL, you should be able to simulate it, and run the actual boot ROM / game ROM (it would be very slow, but much easier to debug than using signal tap).
Great, thanks. ;)
I'll definitely be picking your brain on this later.
I'm guessing / hoping that a fair few instructions on the GTE can be done directly by shifting the first (and sometimes after), and maybe sign-extending some stuff as well?
Along with the excellent info from no$cash on the PS1, I've just been using this PDF to figure out what I need to start implementing for the GTE...
hitmen.c02.at/files/docs/psx/psx.pdf
And in the last hour or two, I've managed to make sense of the basics, and wrote this...
(hey, it's a start, right? :p)
pastebin.com/VQnr1zTd
Now, I realise that you would probably be implementing things in an entirely different way, and there WILL be some mistakes in what I'm attempting, but I think it will work OK, even if I initially need to use twice the normal clock freq to step through all of the instruction states.
If nothing else, it's been fun learning more about the GTE, as I've wanted to write some Verilog for many years that will actually do some useful matrix maths stuff, and spit out some decent polygons.
Just to write a basic 3D renderer on real hardware would be awesome. ;)
Is there anything really glaring that you would do differently in my code btw?
I know that I could just pick groups of bits from the regs directly while doing each instruction, but it is nice to have the wire defines too. I also realise that I will have to make sure I properly register all of the results, but I think it's workable like this?
I just realised that the "wire" defines might be fine for grabbing the bits from the GTE regs, but for writing back to the regs, I should just change all of the "wires" to actual defines or parameters.
The only thing then is that the "wires" make it easier to tell how many bits should be grabbed from each reg, for each value.
hmm. the first of many things to ponder... lol
I'm not as familiar with the GTE as I am the RSP, however, I would take a step back from writing the actual HDL, and work on a block diagram, to figure out what all needs to be in it.
I believe it also used the general purpose register file format, so that adds additional complexity, where you need to have the CPU be able to read / write to any of the 32 registers.
You should also think about adding constants / parameters for the module, one of them being the bitwidth of 32 (I know the actual implementation was 32-bits, however, it wouldn't hurt to provide an N-bit interface so that if someone wanted to, they could tack it onto a 64-bit processor). Besides, it's always good programming practice to try not to hard code things directly in-line.
I'm not sure if it's a verilog quirk, but you are probably better off splitting the design up into a clocked block for the registers, and a combinational block. I would always run into un-expected behavior when I wrote FSMs with everything guarded by the clock. So in VHDL, there is no register type. Instead we would create two copies of the signal / wire being var and var_c. Where on the clock edge, all we do is var
Thanks for the comprehensive reply.
I'll have to absorb this info for a while.
I did see that GTE.txt source before, but completely forgot until you linked to it. :p
I'm decoding the top 8-bits of the opcode for the 22 or so GTE instructions now.
The basic sub-steps of each instruction don't look too bad on the face of it, but the problem is trying to comprehend things like the C / C++ sources in MAME, where they use a lot of macros and inline code for doing clamping and saturation etc.
The capstone link is great btw. I saw a few of those white papers, where various Uni students had looked at implementing the SNES and other machines, and did read the PSX one before, but I didn't realise they'd actually shared the sources for it. :o
That github you posted is superb, as they did manage to implement most of the GTE stuff by the looks of it.
haha - just re-read this old line in their PDF...
"If you are continuing from where we left off, synthesize the project, upload to the board,
open up no$psx, and start back tracing. We are in the middle of the BIOS and entering an
(invalid?) loop right before the white screen comes on in the BIOS animation."
I had EXACTLY the same issue when I was trying to get the PS1 BIOS to boot further on the DE1. lol
With the help of another few comments from no$cash, and a lot of stepping through the code under MAME, I finally found the BIOS routine I had to NOP out. I believe it's something to do with some kernel debugging output that it gets stuck on? I'm not entirely sure what it does.
The routine for initialising the SPU then follows that, which of course haven't implemented yet, so I had to add another NOP for that.
For the "NOPs", I just added this, which patches the BIOS code as it loads the main kernel code into RAM by the CPU at power-up...
wire [15:0] SDRAM_DIN = (BYTE_ADDR==32'h00002834) ? 16'h00 : // Shove in a NOP! (for the Kernel IO redirect thing).
(BYTE_ADDR==32'h0005418C) ? 16'h00 : // Shove in a NOP! (for the first part of the SPU setup routine)
(state==16) ? WRITE_DATA_BACKUP[15:0] : WRITE_DATA_BACKUP[31:16];
And now I just noticed that I was technically only using an 8-bit value for the 16-bit wide bus.
Oh well, it worked. lol
That's great info though. I see that capstone PSX project is in SystemVerilog, but it's not hugely different. I can now follow their GTE code, and see if I can implement it in my own crusty Verilog style. hehe
Regards,
Ash.
Amazing video, so detailed. Thanks!!
Since your video doesn't talk about the 4300, why don't you change the title of the video?
The video talks about the VR4300 (the NEC variant used by the N64), which is exactly the name listed in the title. The R4300 is a different CPU.
@@RTLEngineering There's almost no mention of the 4300. I've seen quite a few TH-cam videos that take some time to get to the point, but there are no details of the "VR4300 Primer" until about the 13:00 mark. It's a good video for newbs and non-engineers, but the title doesn't really match the content. How about "Primer on CPUs and the VR4300"
I think I understand your confusion. This video was presented as an intro lecture to the VR4300 (there were going to be more videos following it), which required some background knowledge / refreshers (i.e. primer to the VR4300 not of the VR4300). It would not be accurate to say it was a primer on CPUs - digital logic if anything, but insufficient to really be called a primer on/to digital logic.
Anyway, I made this video several years ago and would definitely approach it in a different way now.
@@RTLEngineering"Hi, I was originally planning on doing a video on the VR4300, however..."
The rest of the intro was: "..., as I was working on it, I realized that it is worth a series on its own. I also realized that there are some brief miscellaneous topics I would like to cover before diving into the VR4300. "
In other words... I was going to make a single video on the VR4300 but that video ended up being too long, and at the time I was thinking about it from an accessibility perspective (in the mindset of a lecture rather than a technical report or to-the-point short). The video would therefore start off general and then go into the VR4300, which it did. That's the typical format that would be expected of an undergraduate university lecture in computer engineering, albeit with expedited background.
Anyway, I am sorry if you misunderstood the video title. However, I believe it correctly encapsulates the content within. If you are still unsatisfied, then I would encourage you to create your own channel covering such topics - that's why I created mine.