76 (edited by WoS 2015-01-06 23:46:50)

Re: T65 core bug

Nearly there. Lorenztest ok on all CPU tests but two undoc opcodes on the cputiming test and the irq/nmi timing test during the branch instructions. And Wsoltys came with some hint for a bug I'll have a look as well (thanks for the mail  wink ). A few days more plus a project/directory cleanup (with isim sim.) and we can go for a proper release....

Edit: already in the phase doing 1:1 compares between a real CPU stimulated by an FPGA and the t65 simulations -  only the timing of three opcodes left to fix - kept this for the next weekend... big_smile

/WoS

77

Re: T65 core bug

Finally - just checked in a new version of the t65 core (plus a c64 build using it). The core supports all undocumented opcodes and runs with the correct timing (also for NMI/IRQ interrupts) as far as these can be checked with existing test suites. I also did some clean up and improved the comments especially in the instruction decoder section, this should make it easier to check the decoding for specific opcodes. The toughest thing yet was hunting down out the last fail of the Lorenz CPU test: how the real core handles NMI requests while a BRK command is executed. Had to do quite some tests on real 6510 using a FDIL as test harness and compare with simulations (thus it took a little longer). I have to admit I solved this on the t65 core somehow in a brute-force way, but it works now and can be build properly so far - and it opens up some room for improvements later on big_smile

Currently I checked with the C64+C1541 core:
- passes all Lorenz v2.15 CPU tests (also IRQ, NMI  and instruction function/timings; memory map; CPU port) on disk 1 + 2
- passes some initial CIA tests on disk 2 (until the "cia1tab" tests, which shows some wrong register readouts)
- passes 1541 testsuite v0.33 (CPU tests running on the 1541 core)
- and I checked some games, just to be sure it is ok wink

I'll run also some games - ah, mean tests ... - with the VIC20.  Of course there is still the chance that there are still some issues with situations not tested by these suites. But I'd say if ost has some chance to check it with his core as well and it is fine, we can prepare a new release out of it...

/WoS

Re: T65 core bug

Nice work big_smile

[url]http://ws0.org[/url]

Re: T65 core bug

Soon time to toss a random new demo at it again then! wink

80

Re: T65 core bug

Demos might still not work yet, the CPU is just the start to get things done (and released) step by step...
This topic is to discuss/inform t65 issues with core developers and I just want to mention any updates on this front, I'll report anything else (e.g. CIA fixes,...) in the C64 section (or I may open a new separate topic on specific IP here).

/WoS

Re: T65 core bug

Can someone please tell me the relationship between clk and Enable on the T65 core?   Most of the examples I've seen use a 12Mhz clock and a 1.5Mhz enable.  So does that mean the clock to enable ratio needs to be 8:1?  So if I want a 2Mhz enable, I assume I need a 16Mhz clock?   I would actually prefer to use 4:1  so an 8Mhz clock for a 2Mhz enable.

Thanks,

-Scott

82

Re: T65 core bug

It's just clock gating, you can take any ratio you want (and even just set to constant 1, if clk in = cpu clk, when e.g. used on a FDIL or so...).

I think the Replay c64 core uses ~32MHz and divides by 32 (4*8) and the Replay VIC-20 core uses ~26MHz and divides by 24 (4*6) to generate the enable. I did the setup quite some time ago and I would need to have a closer look if you need exact numbers, but as I said it does not matter what ratio you use (the upper limit depends more on the performance of the used FPGA)...

/WoS

Re: T65 core bug

Wow, just diff'd it. You have been busy!

84

Re: T65 core bug

Credits have to go to ost as well. He also did quite some fixes.   As said, I did still some "brute-force solutions" for some of the undoc stuff, I am sure there is also a more efficient way when looking hard enough for it (but I assume noone really cares for now as long as it does what it should do - so it is a Pareto-like solution wink ).

It still has a lot of flaws in the cycles usually not important for "normal use" (e.g. what the address bus shows in certain cycles without explicit bus access) when comparing to a real 65xx. So sooner or later I will definitely write a whole new implementation of such a core, opcode by opcode. I see it similar to the software world, you need to really throw away stuff and re-code to get closer to an optimum and get rid of burdens from earlier assumtions which might not work out well enough.... Most work is setting up proper test sequences and do verification, not at all the coding, though...

/WoS

Re: T65 core bug

I'll be giving it a test in Asteroids shortly wink

Re: T65 core bug

wolfgang wrote:

It's just clock gating, you can take any ratio you want (and even just set to constant 1, if clk in = cpu clk, when e.g. used on a FDIL or so...

Thanks for the info.  clk=>cpu_clk and Ena =>'1' did not work for me.  But clk to enable ratios of 8:1 and 4:1 worked just fine.  Any chance I could get a tarball of the latest update to the T65 vhdl?   

Thanks for the help.

-Scott

87

Re: T65 core bug

scott451 wrote:
wolfgang wrote:

It's just clock gating, you can take any ratio you want (and even just set to constant 1, if clk in = cpu clk, when e.g. used on a FDIL or so...

Thanks for the info.  clk=>cpu_clk and Ena =>'1' did not work for me.  But clk to enable ratios of 8:1 and 4:1 worked just fine.

Depends on the cpu_clk, the used FPGA and the connected stuff on the CPU bus, of course. There is for sure no generic answer to this. Maybe from experience: 1...2MHz on cpu_clk should easily work on any FPGA you can currently buy with a few I/O, RAM and ROM connected. But a 16...20MHz cpu_clk could be already quite a challenge on some, to give an example (without gated clock, means ena=>'1'). Using 16MHz clock and a divide-by-8 enable is quite the same as just run it directly with 2MHz...

scott451 wrote:

Any chance I could get a tarball of the latest update to the T65 vhdl?

Got no feedback how it works on the other cores, but still works nicely for the C64/VIC-20 (and I did quite some other tests recently). So I don't see a reason to wait any longer, attached as intermediate (and "inofficial") solution until Mike got the chance to push back to opencores. If you have any issues/improvements related to this code, please post them here again...

Post's attachments

T65_V313_28feb2015.zip 20 kb, 12 downloads since 2015-02-28 

You don't have the permssions to download the attachments of this post.
/WoS

Re: T65 core bug

I can update the opencores page.

Re: T65 core bug

scott451 wrote:

Can someone please tell me the relationship between clk and Enable on the T65 core?   Most of the examples I've seen use a 12Mhz clock and a 1.5Mhz enable.  So does that mean the clock to enable ratio needs to be 8:1?  So if I want a 2Mhz enable, I assume I need a 16Mhz clock?   I would actually prefer to use 4:1  so an 8Mhz clock for a 2Mhz enable.

Thanks,

-Scott

This "Enable"-signal can be used for different jobs:
1. as Clock-Enable-signal (divide the clock edges/slows the design down)
2. Enable/Disable the Core
(1. and 2. can be used in conjuction)
This signal is one of my most beloved T65 features.

scott451 wrote:

..  clk=>cpu_clk and Ena =>'1' did not work for me.  But clk to enable ratios of 8:1 and 4:1 worked just fine.  Any chance I could get a tarball of the latest update to the T65 vhdl?   

Thanks for the help.

-Scott

To understand this problem you have to take a closer look into MOS's 6502 timings. A typical read-cycle is: Set the address at rising edge "E0" and receive the memory data at the next rising edge "E1", so you have no room for any register stages used by most memory controller.
Simple example: An internal RAM (always with registered address as input and optional registered output data) need a minimum of 1 clock cycle, what means the data is valid after "E1" and not before.

To solve this problem, you can introduce a second clock, 2 or 3 times faster than the T65-clock or use this "Enable"-signal as ClockEnable. The second solution is the better one, because this results in only one clock domain. (and: this approach runs on most Altera's Cyclones and Xilinx' Spartans with more than 100MHz).

Re: T65 core bug

Yesterday, I downloaded the new T65 core, it works more or less fine.

But there are some issues that should be considered for updating. The main issue is the reset. It's like in all old version still unsynchronous, e.g. like in Line 287 and below:

  process (Res_n_i, Clk)
  begin
    if Res_n = '0' then
      Res_n_i <= '0';
      Res_n_d <= '0';
    elsif Clk'event and Clk = '1' then
      Res_n_i <= Res_n_d;
      Res_n_d <= '1';
    end if;
  end process;

It's often stated that altera has few problems with this construct, but this should not be used in xilinx and lattice tools.

A better style is:

  process (Res_n_i, Clk)
  begin
--    if Clk'event and Clk = '1' then
    if rising_edge(Clk) then
      if Res_n = '0' then
        Res_n_i <= '0';
        Res_n_d <= '0';
      else
        Res_n_i <= Res_n_d;
        Res_n_d <= '1';
      end if;
    end if;
  end process;

"Res_n" is only used in this process, but this formulation should be used for "Res_n_i" and "Res_n_d"
in all other processes.

I can't proof it, but I believe that this unsync. Reset causes problems whith higher clock rates.

91

Re: T65 core bug

We had a discussion on this in general - especially about async. behaviour, it is always the question if you want an implementation close to the reality or optimal for the FPGA...

You are right, async. implementations are not optimal for FPGAs, but the mentioned async. reset works fine on Spartan 3E as used on the Replay, just costs a very little more ressources on the FPGA. Btw. the reset is not really anynchronous on the Replay, the timing is also derived from the clock (this is usually also the case if you get it e.g. from a DLL or similar block)... On the other hand there are only a few clock domains and everything is gated, which IMHO helps much, much more for proper timing closure (especially this helps the tools and reduces the interfaces between clock domains, which are hard to cover properly by checks).

On the replay the T65 core runs within a pure ~33MHz clock domain (divided from the DDR RAM clock) and I don't see a speed issue - so it should easily run with a 16MHz clock or a 8MHz clock as mentioned above as well. I also did a STA for my cores, the async. reset is not an issue.

Most people miss to set up proper clock and I/O timing constraints for their design and just take some tool defaults, which means they simply don't know why something fails, as the tools can't check anything.  It is simply not enough to take the code, put it in a design and download to the FPGA, like people are used from microcontrollers. FPGA design is much more than that. Thus, most of my work is without using a FPGA hardware at all, just a workstation (ok, I don't count the hours afterwards playing some games to check the stability of the setup big_smile )

The problem can also reside also outside the CPU core, especially on the bus to the peripherals and memories. Or it is a simple integration issue of the CPU core - e.g. some control signals are not correctly used, e.g. together with memories - here I had most issues to connect properly to the DRAM controller, which had nothing to do with the T65, although this guy got stuck all the time. You need a proper simulation and analysis setup, then you will find the errors and/or bottlenecks of the design. There you can also proof everything you think it could be an issue.

The T65 core is grown over time and the core got modified by several people, thus many things are for sure not optimal in the code. One day it really makes sense to clean up the whole thing, but for now it is working fine and I think it is not worth to spend the effort on it in this phase - I'd say it is better to use and test it thoroughly and fix remaining issues. Then it will be a very good "golden model" for a "fresh" implementation later on...

/WoS

Re: T65 core bug

Please also note that in the Replay library, the reset de-assert is synchronized to each clock domain where it is used.
This is a very standard in the ASIC world, where a sync reset on each flop is more expensive to implement. Perfectly safe if done correctly.

/MikeJ

93 (edited by hoglet 2015-08-29 20:30:45)

Re: T65 core bug

Hi all,

I'm not sure if this is the right place, but I've just stumbled across a bug in the latest version of the T65 core.

The bug is that the interrupt flag is cleared on reset, rather than being set (to mask interrupts).

Looks like this bug got introduced late last year:

r978 | wolfgang.scherr | 2014-11-30 00:27:35 +0000 (Sun, 30 Nov 2014) | 1 line
Mortens atari_2600 version copied back to the lib tree (plus a fix for the undocumented ARR opcode).
Index: hw/replay/cores/lib/cpu/t65/T65.vhd
Code:
-          if RstCycle = '1' and Mode_r /= "00" then
-            P(Flag_1) <= '1';
-            P(Flag_D) <= '0';
-            P(Flag_I) <= '1';
+          if RstCycle = '1' then
+--            P(Flag_I) <= '0';
+--            P(Flag_D) <= '0';
+            tmpP(Flag_I) := '0';
+            tmpP(Flag_D) := '0';
           end if;

The old code sets the flag on reset, the new code incorrectly clears it.

I'm using the T65 core in a 6502 In-Circuit Emulator, and this bug caused an issue when it was used in an Acorn Electron.

Many thanks for all the great work on this core!

regards

Dave

94

Re: T65 core bug

Oh, thanks for that, Dave!

It's exactly the right place ;-)

I think it happend when I merged a new version out of the C64 and the Atari core. Will check it out and update afterwards...

/WoS

Re: T65 core bug

hoglet wrote:

Hi all,

I'm not sure if this is the right place, but I've just stumbled across a bug in the latest version of the T65 core.

Dave

Sorry, I completely missed this post! WoS, u fixing this one?
Cheers,
Mike

96

Re: T65 core bug

Me too...   Yes, I am on it, just want to verify properly before I check it in.

/WoS