65ORG16.b Core

[ElEctric_EyE]

aha, I see. I think I've added them.
Do you see? So I didn't wipe the previous additions out?

Thanks for your patience!

[BigEd]

Right... your commits are certainly committed! Only thing is, they are committed to the master branch, not to the 65Org16-master branch.

Here they are: https://github.com/ElEctric-EyE/verilog ... its/master

I don't think this matters a huge amount. In some ideal world this family tree of variations would be picking up small bug fixes from each other by merging code patches. But I suspect the files will diverge enough that it will be too difficult to do that. Maybe Arlet will have some ideas about this.

Maybe it was even bad tactics for me to use a different branch.

Anyhow: bear in mind, your project and mine both have two branches, which mean they both contain two versions of the core, so you do have to take care which version you're working on. In my case, the versions are

• master - just like Arlets
  65Org16 - the basic 16/32 bit variation

In your case, the versions are

• master - your multi-register 16/32 bit variation
  65Org16 - the basic 16/32 bit variation

If this is all too complicated, we can find a way to fix it up.

I'm glad you're in github though - I hope you're glad too!

Cheers
Ed

[ElEctric_EyE]

Neat! I'll learn more about github as I go along...

BigEd, I had intended to fork from your design, especially since I had built on what you had changed... But maybe it is for the best, since I don't care for BCD, and it seems you are pursuing it? and next I will pursue a second 16 bit 'B' accumulator...
Thanks for helping me along though!

My BCD trimmings do need supervision, to make sure I've not trimmed too much, I've not tested my mods yet!

[BigEd]

Hi EE
in my code, I made the BCD conditional,so it's still visible in the source but not active. I think you took your working copy before I did that, but you took your github fork afterwards.

I see you've done another incremental edit, with a comment: that's a good way to proceed. You should be able to re-download just that single changed file.

I've deleted the 'master' branch on my fork, at least for now- so if you like, you can delete your fork, recreate it, and it will only have the single branch which it should have, the 65Org16 one. You would then need to re-paste your changes. Let me know what you think. I've taken a copy of your state of play, so I think we can re-play it if we need to.

Maybe I've gone overboard with this branch naming business.

Cheers
Ed

[ElEctric_EyE]

Ok, I'll have to try to up it again later tonight. At work today...

Ive run the simulation at 12ns to see when it would complete the copy loop and how long it would take to write to approx. 4GB. But for some reason, when it gets to $1000C001, then next memory address it writes is $AA55C002. Like the cpu did not recognize it was in indirect index mode.

[Arlet]

By the way, I've also made some changes in mine that aren't in your versions yet.

I've changed the blocking assignments to non-blocking assignments for all the combinatorial parts. Functionality is still the same, but it's a better style.

[fachat]

ElEctric_EyE wrote:

Ive run the simulation at 12ns ....

BTW: any info / link to comprehensive information how to do simulation in ISE WebPack? I'm afraid my ghdl approach won't really take me far as it requires explicitly mentioned delays.

Thanks
André

[ElEctric_EyE]

fachat wrote:

...BTW: any info / link to comprehensive information how to do simulation in ISE WebPack? I'm afraid my ghdl approach won't really take me far as it requires explicitly mentioned delays.

Thanks
André

I can't help with the vhdl or even verilog file for a testbench file for simulation....

In ISim, I just right click on reset, force constant to 1 (active Reset) for 1ns duration. Then right click O2, force clock, leading edge at 0, trailing edge at 1, and period @12ns.



EDIT: I previously responded hastily, reclarified...

[ElEctric_EyE]

Arlet wrote:

By the way, I've also made some changes in mine that aren't in your versions yet.

I've changed the blocking assignments to non-blocking assignments for all the combinatorial parts. Functionality is still the same, but it's a better style.

I'll update mine with those updates and post tonight. I'll try to do it right this time...

[ElEctric_EyE]

BigEd wrote:

...I've deleted the 'master' branch on my fork, at least for now- so if you like, you can delete your fork, recreate it, and it will only have the single branch which it should have, the 65Org16 one. You would then need to re-paste your changes. Let me know what you think. I've taken a copy of your state of play, so I think we can re-play it if we need to.

Maybe I've gone overboard with this branch naming business.

Cheers
Ed

No, it's good you try to keep things in good order. Always requires more effort on all parties involved. I certainly have no problem with that!

So, I've deleted my repositories and forked off your current 65Org16 master branch. So now I see there are 3 master "branches": Arlet's, yours and mine. Cool!

Tonight, I'll compare Arlet's new combinatorial block to non-block edits (<= to =) to his master branch, and add them to mine too.

Also, I have to investigate the problem I've mentioned earlier. Sounds like maybe I have an address decode problem, or maybe running the synthesis too fast. Will investigate and report back.

[BigEd]

All good...

By the way, if you've accumulated a number of changes, the best practice way to get them into github would be to consider them as a number of commits: so try to split them out by editting them in in succession to the present state of play. And put in a descriptive commit message for each one.

The trick with this, is for the last one in the series, just paste in the whole current state of your working file. Then you know for sure that your final state is exactly what you intended. But you might have produced

• - a commit to remove BCD
  - a commit to add a second accumulator
  - a commit to convert the style of some assignments
  - a commit to fix up some bug with indexed addressing

or whatever the developments might have been.

The reason is that some other fork could in principle take one of your changes or fixes and apply just that change. Also, it's easier for someone else to follow your development and learn from it, or comment on it.

This is my series of commits - there's a knack to describing a piece of work in a few words, or splitting a day's work into three or four distinct tasks, but I think it's worth it.

Cheers
Ed

[Arlet]

ElEctric_EyE wrote:

But for some reason, when it gets to $1000C001, then next memory address it writes is $AA55C002. Like the cpu did not recognize it was in indirect index mode.

That sounds like it's wrapped around the memory, and started to overwrite it's own code.

[BigEd]

fachat wrote:

BTW: any info / link to comprehensive information how to do simulation in ISE WebPack? I'm afraid my ghdl approach won't really take me far as it requires explicitly mentioned delays.

Perhaps you could download my 65Org16 project from github, then you could

Code: Select all

  cd simulation-isim/
  ./run_isim.sh

Then have a look around the directory. The script builds the simulator and runs it. To build the simulator, there's a project file which just lists the sources. Those sources can be either verilog or vhdl (or a mixture). I've taken a shortcut to ease maintainability, so instead of listing all my sources I list just the testbench module which does include timings, and the chip module which is what I will synthesise.

Code: Select all

verilog work testbench.v
verilog work ../build-xilinx/chip.v

The chip module uses verilog's file inclusion mechanism to pick up the remaining source files. I could instead have listed them in the project file, so to substitute in a vhdl i2cslave design for the present verilog one, I might rewrite my project file as

Code: Select all

verilog work testbench.v
verilog work  ../system-rtl/gop16.v
verilog work  ../system-rtl/ram4k.v
vhdl work ../system-rtl/i2cslave.vhd
verilog work  ../system-rtl/tinytestrom.v
verilog work  ../cpu.v
verilog work  ../ALU.v

and if the interfaces matched up it might actually work!

Hope this helps a bit

Cheers
Ed

[BigEd]

also, google for isim tutorial and have a look at the version appropriate for your version of webpack.

[ElEctric_EyE]

Arlet wrote:

ElEctric_EyE wrote:

But for some reason, when it gets to $1000C001, then next memory address it writes is $AA55C002. Like the cpu did not recognize it was in indirect index mode.

That sounds like it's wrapped around the memory, and started to overwrite it's own code.

No, the program residing at $FFFFE000-$FFFFFFFF starts writing $A5A5 at $10000000. It runs correctly up until it is supposed to write to $1000C002, that's only 48K. I've tested it repeatedly now and I feel confident in the address decoding... Here is the listing again:

Code: Select all

 *= $FFFFE000		        	;START	COPY PATTERN $AA55 
				                  ;FROM $10000000 TO $FFFEFFFF (($FFFE X 10000) + FFFF)
				                  ;
FFFFE000	LDA #$0000	      ;00A9 0000
FFFFE002	STA $0000          ;0085 0000
FFFFE004	LDA #$1000	      ;00A9 1000
FFFFE006	STA $0001          ;0085 0001
FFFFE008	LDX #$FFFE         ;00A2 FFFE
FFFFE00A	LDY #$0000         ;00A0 0000
FFFFE00C	LDA #$AA55      	;00A9 AA55
FFFFE00E	STA ($0000),Y      ;0091 0000
FFFFE010	INY		          ;00C8
FFFFE011	BNE FFFFE00E	    ;00D0 FFFB
FFFFE013	INC $0001          ;00E6 0001
FFFFE014	DEX		          ;00CA
FFFFE015	BNE FFFFE00E	    ;00D0 FFF6
FFFFE017	JMP FFFFE017 	   ;004C E017 FFFF

Here's the timing at $1000C0001, working. And the next at $AA55C002

One thing else I have noticed: Look after the bne (00D0) and bne offset (FFFB). It is trying to execute the 00E6 (INC zp)

EDIT 5/28/11: Fixed LSB of the JMP Vector
EDIT 5/27/11: Fixed $FFFFE005 from $0000 to $1000