And if I can't convince you to use the Suska or some other core as a tool in this project, which I think is a good idea even if you must complete it with tg68, I do still very strongly suggest simulation to be an important tool for you to use. It will help you understand tg68 better, faster than reading VHDL code and guessing about it with your boot screen colors. Simulate with tg68 and you're doing it the tg68 way. No matter your reason to choose to work only with tg68, simulation is a valid and very important tool. Don't ignore it. Nothing else will be more helpful to you in gluing and enhancing tg68 than simulation. Use it.

And if you have not already, at least use the Suska or another core to prove your PCB design. You can do that with an input-only reset. If you can't make it work with easier to fit cores, that helps you find problems n the PCB, or prove that it works well. If you don't prove the PCB, that makes it a great deal harder to debug the entire design together. Knowing that the PCB works with SOMETHING lets you focus on the VHDL as source of problems getting the tg68 design to work. Not knowing your PCB is good, while ignoring simulation, means you don't know where problems are coming from, and you cannot focus your attention where it needs to be.

It hasn't sounded like you have done simulation or really proven the PCB. No serious person with experience in this kind of thing will ignore simulation, and those who have criticized you before, those who you have something to prove to, will be laughing if you are not doing this. They will be laughing if you are not using any tools available to prove the PCB. Don't give them these reasons to do that. If you embrace simulation and other cores and tools, then they will owe you respect for being so professional about this, and for greatly increasing your chances of success.

Simulate. Do it.

OK, last post for tonight. Another reason to use other cores as a tool is to learn what is and is not important for TG68 in your design. Do you need the FC* pins? Get the Suska core runnign fully on your board, and then disconnect them. Does it still work, or did it stop working? That tells you if you need them or other pins missing from TG68. Then you can ignore what doesn't really matter, and focus on what is important to add to TG68. I'd say that's a good reason to do it.

someone in another forum has mentioned something that may be useful in your use of tg68 on a normal 68000 bus.

http://eab.abime.net/showpost.php?p=814784&postcount=2

Yes I already have that because someone maybe him posted that on another forum but this can't help me as I checked few days ago. Also I know about bus differences. Either way I have running core on standalone version and few days ago i created address bus tracking with counter to flash a LED on board. Code is on my site. So in this stage I need to find other differences between real Mc68K and TG68. Maybe my approach from the start was not ok, so few days ago I was thinking to get first TG68 core running standalone without any connection to the A600 board, and it was few minutes job. Now just need to see what signals are identical and what are not to the original CPU. But with clk_enable everything makes sense with that I can make core start at exact time to get synchronized with board.

well, as that post says minimig had to adapt tg68 onto the more normal minimig 68000 bus, you really should look at minimig sources to see what they did. also, a simulation will let you look at waveforms and see what is same or different then what 68000 databook says. i will continue to nag you about this, as saying you still need to see which signals are different means you are not doing these two things. and not doing at least one of these is a mistake imho. at least look at what signals minimig had to adjust for tg68.

is ignoring how other people accomplished this same connection (tg68 to 68000 bus) and ignoring simulation part of needing to do this project with tg68 to prove your abilities?

As I find time, I plan to work on a tiny simulation of the Suska wf68k00 core. This will require a bit of assembly language and a memory of some kind to store it. I'll probably hack up a simple RAM model rather than use something resembling a real RAM requiring a memory controller for this experiment. And may take a while, especially as I have final project for class to do. But maybe in a month or so. As the guy in my previous link suggested, I'll use Easy68K to make the tiny software for this simulation, so we can see it reading an instruction or two and one of those instructions will cause a write, and then a readback of that write for a comparison check. Nothing fancy. When I get that done, I'll post it somewhere, and I'll encourage you to try and swap out the wf68k00 for the tg68+wrapper and use comparisons to figure out which tg68 signals are still different and help figure out how to adjust them in your glue logic. It'll probably be faster to look and see what Minimig did, and I still very much encourage that. Port it to a VHDL wrapper, as I assume that Minimig probably does this in Verilog.

And as I work on this simulation, I'll also be learning and working on testbench things I can reuse in my Zorro to Wishbone bridge project, though at some point this will need to include a 68000 to Zorro bridge as well, or at least beef up the Dragonball/68000-Wishbone bridge that looked too simple for my needs. I'll probably start off using the ao68000 processor with native Wishbone bridge though, as that's already got one side of my bridge. I want to port everything I do for the Zorro bridge to both VHDL and Verilog anyway.

What I'd really suggest for your design, is to make a level of wrapper around TG68 as a component, and instantiate this wrapper in your acclerator_top. It seemed that accelerator_top was becoming this wrapper itself. This way, your accelerator_top can easily swap wrapper+tg68 for any other processor core that fits onto a normal 68000 bus, should I want to pop the Suska processor core in there to play around, or perhaps a new/improved tg68 will be more standard bus like by itself someday, and also lets you put things like a memory controller beside ProcessorX instantiation that works with anything else on the normal 68000 bus. This will make working on your accelerator_top part much easier in the future.

Let me give an example of why i think simulation is so important that I won't shut up about it, even though it seems you are not very interested.

For the vhdl rtl class i'm taking now,nwe have a group project to present next week, and my portion of this project is a vga monitor controller and display engine (draw various shapes based on a couple 1bit grids of information from a game logic component). My first step is of course to get hsync and vsync signals doing something legal and see anything at all onscreen. I had two major reasons to simulate before I hooked a monitor up to my fpga board.

1. make sure i don't make a mistake that fries the monitor, releasing the precious blue smoke from it.

2. have a good idea that my stuff works at all, and syncs look like vga specs say they should, which includes time of 1 and 0 values.

simulation said this was great. so I hooked up my monitor. nothing but a "move your mouse" sort of message, i guess it thought the "computer" was in sleep/standby/something mode. This was not an illegal screenmode message, it said it saw nothing at all on my va port.

huh? why? This could be comparable to black screen for your cpu debug method. What does it really mean?

I checked my vga port with my cheapo but handy usb oscilloscope tool. no syncs at all.

For me, it was a clue to look at my setup, and i founf that the ucf file fir xilinx ise did not attach to the project properly. It was listed, but was not under my top entity as expected. I removed the ucf file and readded it, ise got it right this time, and resynthesizing the exact same code got me a blank white test screen, and i knew it worked.

for your method, how do you use a black screen to determine what to look for? It's too hard to guess what might be wrong imho, and simulation gives you more clues than just the obvious things like dtack is inverted. What else might need looked at?

Simulation let me know what was good, so I didn't end up spending lots of time trying to fix vhdl design code that didn't even have a problem. It's a great tool. Use it.