Ok now I have core running and sometimes Amiga board detects accelerator. But there are problems with dtack and r/w. I had to provide reset signal thru 2 registers and I inverted DTACK so its working now, next stage is to see problems with R/W and need to think about FC0,1,2 signals as they may be important here. As you know TG68 don't support FC signals but it is easy for me to create those signals, 10 minutes of work.

So first I need to think about synchronous and asynchronous reset, and solving R/W and DTACK, and that is for today work.

I'm happy to hear you have made some progress. The FC signals might be present in the Suska 68k core. I don't remember if they had logic driving them, but the ports were there as I remember. If they are easy to add then great, TG68 will improve.

Good goals.

Though I'm surprised you need the double-register thing for reset. It's important to get your reset working well, so this is a good goal to work on with the dtack and r/w this week. (Don't feel bad if it takes longer than a day) That signal is about the only one that I've been discouraged from doing that with. The project I did that with worked with those regs, so it may be fine, just not necessary. These two serial registers are typically present to help avoid metastability problems, where the signal is neither a 1 or 0 value, but sortof stuck somewhere in the middle that is very hard to predict what is happening. The registers help get that situation cleaned up between clocks so the output will not have that problem. It is typically an interaction between different clock speed regions such as when two different clock signals at different speeds have their edges close but slightly different from each other, and when capturing asynchronous data on a clock edge when the data value changes very close to the clock edge giving a setup or hold time problem. As we do not typically capture reset on a clock (such as look at it inside of an "if rising_edge(clk)" section), we should not need to worry about that. I would suggest trying to remove these two reset registers. If you only make use of reset value on a clock edge, then I'd suggest considering to change that at some point.

How do you have your reset connected between your top entity and the TG68 instance? From top port to your two registers, and output of these goes to TG68? Do you use or create reset inside of a process?

How do you know when Amiga motherboard detects the accelerator and when it does not?

Also, how did you determine that dtack needed inverted to work for you?

1) Why is DTACK on TG68 inverted ?
2) Why I need to use NOT statement for reset ?
3) Do I need to solve problems with FC signals FC 2 to 0 "111" for CPU space) to get valid data reading with R/W signal and DTACK?
Those are main 3 questions I need to find answers.

Why these things are inverted is probably just something to guess about. As long as you know about it and get it right for your design, then why they inverted things really is not important. Maybe it saved some room in the overall minimig+tg68 design, maybe they just liked it better, it doesn't matter. Maybe they are just more comfortable with 1 being true and 0 being false in all cases, and whatever reason for motorola inverting that for a pcb designer does not apply inside an fpga. Don't worry more about why. Just figure out what they are and adjust things as needed for your accelerator to be correct. Your first two questions don't need why to be answered.

Question 3 may be important though. Check amiga schematics and see if they go anywhere. And check minimig (both original with hard motorola chip and with de1 minimig+tg68) to see if it looks like anything wants them. Amigaos does not do any real separation of users or os stuff, no protection etc. So fc* may not be important for amiga.

You seemed to think that adding the fc* pins would be an easy and fast thing to do. I'd guess more than 10 minutes, even if it takes a couple days then try to do that. If you are confident that your inverters on dtack and other signals are correct, then move on to this. They are present in the suska wf68k00 but I don't remember if they are really functional. And I don't know how important they are on the amiga motherboard. Tg68 does say that some bus things were left out because they were not needed by minimig. Since minimig intends to be an amiga inside the fpga, perhaps amiga does not use them. But if it is easy job to implement them, then i'd go for it and do that.

P.s. I don't see answers to questions asked to you. :)

And I'm still learning too. I'm working on a project for class this week using PicoBlaze, and the user manual for that has a two-flipflop filter thing on the reset. I'm not sure if this is how you've done your two-flipflop thing or not. Maybe there's a good reason to have it this way that I just don't understand yet.

I think it's the asynchronous vs. synchronous reset problem, already discussed elsewhere
in this forum. The thread is http://opencores.org/forum,Cores,0,4746

Hellwig

Oh my god I didn't see that there is another page of this topic of mine. I have 1024x768 resolution so didn't see all the parts of screen :) I ll answer today :)

First of all Accelerator is detected when Amiga passes some points of system testing so for every system part that is not working you get some color on the screen. And when there is some color that's the situation when you know that processor is working or some of the parts.Only in situation when you have black screen there is no CPU present. And yes I think that some of the problems are related to reset, because sometimes maybe another part of board do something with that reset signal. Also there are some info regarding to MC68K reset who is bidirectional signal ??? So this needs further readings, to find relation for other signals. But there are some relations to HALT or BERR and need to read about that. But lets focus on those steps I said earlier. And maybe I ll first think about reset. Like I said I don't know anything yet because maybe there are more inverted signals on TG68 but I ll check minimig&TG68 documentation.

Ugh, gave up trying to reply with android phone browser again. Ate my reply twice. :/

Since in reality the tg68 only has a reset input and no reset output, you can simply invert resetN if needed and connect to tg68's reset port and be done for now, which is much simpler. But here's how I think to do a bidirectional reset:


I didn't realize the 68000 reset is bidirectional. m68000um.pdf rev 9.1 page 35 says the processor drives/asserts reset when it gets a reset instruction in software, and otherwise only listens to reset. I'll guess that the Amiga motherboard has an open-drain (open collector? I always get them confused) wire with a pullup to 5V. Nothing actually drives a 1 onto this reset PCB wire, only a 0. So you need an FPGA IO that can handle this, and this will mean 2 or 3 reset signals inside accelerator_top. A port for accelerator_top is the name of your reset pin, I'll try resetN as an example for this, and this is the name you connect your .ucf constraints file to accelerator_top.

It looks like TG68 is ONLY an input reset, it does not support driving reset to motherboard. Remember, TG68 is meant to be a minimal thing to run most 68000 software with a system that fits onto it, and I imagine that Minimig was altered to fit tg68 compared to the original design using hard Motorola chip on the PCB. It is not meant to be a true clone of 68000 pins, which is more what you are trying to do. TG68 will need some glue logic to become a true 68000 clone for a true 68000 motherboard, which is what you are designing in accelerator_top around the tg68 instance.

As tg68 does not have a reset_out, this may be overkill, but may be useful for other 68000 cores.

very simplified quick and dirty hacking, may need inverted or syntax-corrected. Anyone please feel free to correct anything I've got wrong in doing this so quickly.

entity accelerator_top is
port (
resetN : inout STD_LOGIC; --system reset from and to motherboar
...
);
end entity;

architecture reset_example of accelerator_top is
signal resetN_in : STD_LOGIC; --active low reset input FROM motherboard
signal resetN_out_enable : STD_LOGIC; --enables tg68/wf68k00/etc. to drive 0 TO motherboard
signal resetN_out : STD_LOGIC; --value to drive out TO motherboard, only a '0' NEVER a '1'
signal reset_to_tg68 : STD_LOGIC; --inverted from motherboard, active-high into tg68
signal reset_from_tg68 : STD_LOGIC; --fictional active-high reset from tg68

...
begin
resetN_in reset_to_tg68 --tg68 does not reset itself
--drive our '0' resetN_out value onto FPGA pin only when tg68 tells us to
--when tg68's own reset_out is a 1 (active high output from tg68)
--when 68000 is not telling us to reset the motherboard, then output a Z,
--which is really a disconnect. This removes our '0' reset value from
--going onto the FPGA pin when we do not want it there. We only want to
--connect our '0' output to the FPGA pin when the tg68 reset_output is 1
--and not when tg68 reset_output is 0 or other possible values.
resetN else 'Z';

--pretend that tg68 has an active-high reset_out signal, which is '1' when it
--wants to reset the motherboard due to a software RESET instruction
--tg68 does not actually have this output, but pretend it does for this example
i_68000: tg68 port map(
reset => reset_to_tg68, --active-high reset from motherboard
reset_out => reset_from_tg68, --active-high reset driven by tg68
... );

resetN_out reset_out_enable
...

end architecture;




Now, using the Amiga screen color error codes as your debug method wil leave you frustrated, and it will take a lot longer than doing a simulation. Looking at simulation waveforms will give you much more information than a black or a red or a purple screen. As you're accelerator_top needs to look like a Motorola 68000 chip to the Amiga motherboard PCB, you need to correct and add to the simplified TG68 bus for this. Simulation waveforms will do a much better job showing you which things are inverted, which things might have changed timing or other details than any screen color possibly can. I very strongly encourage you to set up a testbench that pretends to be a motherboard to your accelerator_top, put some memory in it and write a tiny software that will let you see a few read and write cycles on the bus, make a clock and reset signal in testbench, and look at resulting waveforms of what tg68 does. This will much better tell you what glue logic you need beside tg68 in your accelerator_top design to correctly work with the real Amiga motherboard. Your goal, which you have begun with dtack and r/w investigations is to make accelerator_top look like a true Motorola 68000 chip clone. And if you depend only on boot screen colors to debug things, then you are doomed to failure of the project.

Take a week or two of effort to make a testbench, and that will save you weeks and months of guessing why you have a black or red or purple etc. screen color. Compare your simulation waveforms to Motorola/Freescale databook waveform examples and adjust your glue logic design until it matches. Then, and ONLY then, synthesize it into your board and try to boot the motherboard. Things in this project will go MUCH faster this way. Trust me. This is what I do at work using Verilog design of much more complicated ARM SoC chips, I'm a verification engineer. (Going to school to learn RTL design creation and VHDL language) If all you need to do is invert dtack, it's much easier to see that in a waveform picture than to reverse engineer what the TG68 code does, and decide if that matches the Freescale databook pictures or not. If many signals are different in TG68, reverse-engineering them to know what they actually do and then compare to Freescale's picture is a huge effort, especially since they did not comment or document anything at all in tg68 design. (a serious sin in my opinion, the idea that code documents itself is terribly unhelpful, believe me, I spend enormous amounts of time at work reverse-engineering things that could go so much faster if only they commented things well. I find "code documents itself" philosophy to be a gigantic waste of my time.)

And I again also very strongly suggest you look at the wf68k00 core used in the Suska Atari project. (same idea as Minimig to Amiga) It's much better commented, and I think you will find it easier to work with than tg68 is. Please, take a look at this, and explain your choice to change to it or why you would rather continue with tg68 in your project.
http://download.experiment-s.de/Suska-III-C/2K11B/Configware/rtl/

Suska's WF68K00IP_TOP has a good example of the bidirectional reset.

Consider WF68K00IP_TOP is an equivalent of your accelerator_top, and WF68K00IP_TOP_SOC is equivalent of your tg68 instance.

My only complaint looking at Suska's 68000 core is the use of the bit and bit_vector types. If it was me I'd go through and change bit to std_logic and change bit_vector to std_logic_vector. I don't understand why to have that mixed with other things being std_logic and std_logic_vector in the same file. And this is not a serious complaint, I've simply been encouraged to only use the std_logic* types and to not use the bit* types.

Briefly continuing my brief look at the Suska wf68k00 core, I believe they have already done most if not all of the things you have started and need to complete doing to tg68 to get it working in a real 68000 PCB. Please, look at it. Try it instead of tg68, even in your simple what color is the boot screen test.
WF68K00IP_TOP is the top entity to connect ports to FPGA pins the same as your accelerator_top is your top entity to connect ports to FPGA pins. If this works, consider renaming WF68K00IP_TOP to accelerator_top for this version of youru project, storing the tg68 version in archive for later.

Then, if you like, continue working to glue tg68 the same way. But I really believe that the Suska 68000 will get you to your goals for this FPGA accelerator project much faster than using tg68 will.

And have you set up a subversion or git or similar checkin repository system for your design code? It's free to run on your own computer. Do it. And use it. Have you done it yet?

I remember seeing a testbench somewhere in Suska project some time ago, but I dont' see it in latest version download. Maybe they removed it recently or maybe I remember wrong or just didn't understand things well enough back then and was wrong in believing that. But have a look at variou versions and see if you can find a testbench. If they do have one, use it. Simulate Suska as it is, then replace their 68000 core with your accelerator_top and compare. If I'm wrong and there is no testbench, make one. It can be a lot of work, but it really is worth it.

And to continue my propoganda to change to the Suska 68000 core, compare the portlists to TG68, and then compare to Motorola/Freescale pinout. It seems that these may be better comparisons to your accelerator_top design level:
WF_SUSKA-III-C/wf_suska_spartan3_core_ste_top.vhd
or
WF_SUSKA-III-C/wf_suska_cycloneII_core_ste_top.vhd


Compare these to each other:


entity WF68K00IP_TOP_SOC is
port (
CLK : in bit;
RESET_COREn : in bit; -- Core reset.

-- Address and data:
ADR_OUT : out std_logic_vector(23 downto 1);
ADR_EN : out bit;
DATA_IN : in std_logic_vector(15 downto 0);
DATA_OUT : out std_logic_vector(15 downto 0);
DATA_EN : out bit;

-- System control:
BERRn : in bit;
RESET_INn : in bit;
RESET_OUT_EN : out bit; -- Open drain.
HALT_INn : in std_logic;
HALT_OUT_EN : out bit; -- Open drain.

-- Processor status:
FC_OUT : out std_logic_vector(2 downto 0);
FC_OUT_EN : out bit;

-- Interrupt control:
AVECn : in bit; -- Originally 68Ks use VPAn.
IPLn : in std_logic_vector(2 downto 0);

-- Aynchronous bus control:
DTACKn : in bit;
AS_OUTn : out bit;
AS_OUT_EN : out bit;
RWn_OUT : out bit;
RW_OUT_EN : out bit;
UDS_OUTn : out bit;
UDS_OUT_EN : out bit;
LDS_OUTn : out bit;
LDS_OUT_EN : out bit;

-- Synchronous peripheral control:
E : out bit;
VMA_OUTn : out bit;
VMA_OUT_EN : out bit;
VPAn : in bit;

-- Bus arbitration control:
BRn : in bit;
BGn : out bit;
BGACKn : in bit
);
end entity WF68K00IP_TOP_SOC;





entity TG68 is
port(
clk : in std_logic;
reset : in std_logic;
clkena_in : in std_logic:='1';
data_in : in std_logic_vector(15 downto 0);
IPL : in std_logic_vector(2 downto 0):="111";
dtack : in std_logic;
addr : out std_logic_vector(31 downto 0);
data_out : out std_logic_vector(15 downto 0);
as : out std_logic;
uds : out std_logic;
lds : out std_logic;
rw : out std_logic;
drive_data : out std_logic --enable for data_out driver
);
end TG68;


Considering the things you have asked for help using TG68, which of these two things do you prefer now?

Yes your thinking is like it should be but believe me project is started because of TG68 so it must be finished with this core. I have suska core and ao68K and all of them are much better, faster with more info but like I said I don't want to change project. Even few people wanted to give me finished codes for j68 or k68 but I didn't want that.
So project continues with TG68 and even someone wanted to give me something finished don't want because I must prove myself lot of thinks regarding of using TG68 core it is principle because noone who worked with this core didn't wanted to help me to answer just 5 questions, even tobiflex didn't want after 2 years of begging.

Regarding your code I checked and it is ok but for real usage it needs agan bidirectional voltage level shifter if we want to back that RST to A600 board so this option is not predicted in my design so I cant do it, but if I somehow find out that this could be a problem I ll find a way have some ideas...

If this is a "use tg68 just to prove that I can" thing, ok. But consider that a grest deal of medicine is learned using mice instead of prople, and then applied to people. I think that a different 68000 core like suska will help you better understand things. Then you can be better prepared and experienced to go back to your tg68 version and finish that.

Let's do this. :)