|
TG68 starting problem
by majsta on Apr 6, 2012 |
majsta
Posts: 13 Joined: Jan 24, 2011 Last seen: Oct 25, 2017 |
||
|
Here is code but there are no clk,reset,dtack informations. I just don't know how to enable proper start of the core. Nevermind about ALVT devices but can someone help me to get TG68 core started because I have no idea how to set relations regarding clk,rst, and dtack and maybe other signals behavior.
top.vhd (5 kb)
|
|||
|
RE: TG68 starting problem
by amigabill on Apr 7, 2012 |
amigabill
Posts: 34 Joined: Dec 14, 2008 Last seen: Dec 13, 2022 |
||
|
Have a look at what other projects using it do. Minimig and I'm not sure what else make use of tg68. Suska uses another m68k core and it should connect similarly. Check the docs for the suska 68k core and motorola/freescale docs for how these are ecpected to look. Clock likely just runs forever. Reset ultimately connects to your motherboard reset. For simulation, reset should be asserted for a while at the beginning, then release and may not assert again unless you need to check a second reset later. The first reset will be needed to get everything to expected initial states, that's how you initialize hardware compared to c code giving a value at declaration. Other signals I'm not familiar with. Motorola/freescale docs might have some waveforms for powerup time, if so then do that. When connected to motherboard then the board and tg68 should themselves be ready to go, unless tg68 lacks something important. Board will provide rst and clk, though you may have a faster clock running the fpga and use an edge detect on motherboard clock for events on that side. I don't know if board drives others or the cpu, but either way I don't expect your glue needs to worry about it except for simulatio. I hope you are working on simulation about these questions. :)
|
|||
|
RE: TG68 starting problem
by majsta on Apr 8, 2012 |
majsta
Posts: 13 Joined: Jan 24, 2011 Last seen: Oct 25, 2017 |
||
|
Yes I know but there is no example like something:
process (clk_7Mhz, TG68_reset) begin if TG68_reset = '0' then -- WHAT elsif rising_edge(clk_7Mhz) then -- WHAT end if; end process; |
|||
|
RE: TG68 starting problem
by ka6s on Apr 9, 2012 |
ka6s
Posts: 2 Joined: Feb 5, 2009 Last seen: May 15, 2012 |
||
|
Okay - I haven't looked at the core = but in my not so humble opinion - you are whining that someone hasn't given you all the answers. Set up some simulations and give it a try! If you become a practising engineer there isn't going to be someone to hold your hands! Do some experiments - they're free and it only costs you a little time!
Now - what I know from using a REAL 68K might help a bit. Reset is likely asynchronous set, synch clear. You can look at the code and see where it goes to figure out whether you need to synch it up or not, i.e. doesn't go raw into all the processes? That wound work in an ASIC. Next - if I recall - if you ground DTACK, a real 68000 runs without bus wait-states. It also had an asynch spec to it - but if you made a setup time relative to the leading (I think) the timing was predictable. Ground DTACK - feed a NOP into the processor Data bus and see if the address lines increment. If they don't -try DTACK the other way. |
|||
|
RE: TG68 starting problem
by majsta on Apr 9, 2012 |
majsta
Posts: 13 Joined: Jan 24, 2011 Last seen: Oct 25, 2017 |
||
|
Thank you but I m not whining and I m not engineer and I ll never become one :)
I have done all of the simulations but codes I have for simulations can't be used to generate file so I need to replace them. |
|||
|
RE: TG68 starting problem
by amigabill on Apr 11, 2012 |
amigabill
Posts: 34 Joined: Dec 14, 2008 Last seen: Dec 13, 2022 |
||
|
Yes I know but there is no example like something:
process (clk_7Mhz, TG68_reset) begin if TG68_reset = '0' then -- WHAT elsif rising_edge(clk_7Mhz) then -- WHAT end if; end process; I hadn't noticed the vhd file you included before. I don't see any process in there, not even the shell you have above. Where do you need to do these things, and what else do you need to connect stuff in here to? What are the ALVT things? I'd not use TG68 in the top accelerator_top port names now, as I think you'll need to separate that later. They can connect now, but I'd choose different naming scheme for your accelerator_top port names and connect them internally to TG68. Can you give us a block diagram of how different things fit together, and where in this diagram you are talking about? One block is TG68, one block a memory controller, another block is the motherboard connection, and whatever other blocks of glue logic and things we don't know to guess are in your design. When reset is asserted, set any registers to initial values. We don't know what registers you may have, or what values you want them to go to on reset, so we can't write the code for you. When reset is not asserted, then other stuff happens on rising edge of the clock. We don't know what you want to happen on clock edges, so again we don't know what to tell you to do there. Especially since we don't know where in your design you need help on this. If you're asking about how to design a memory controller, then you will get very different what to do on a clock edge answers than if you are asking about a bus arbiter. Are you making a counter? A state machine? A data register? A Fifo? A decoder? Do you use or need variables, or only signals? Inside the rising_edge clock if section, you can have if conditions, case blocks, etc. There's plenty of examples out there for process code with a reset and a clock edge. I've been looking at a lot of that sort of thing for the VHDL class I'm in now. Taking an example and understanding how to interpolate that into exactly what you want to do is part of being an engineer. If you don't want to be an engineer, then you're working on the wrong project. That's what this is. If you want a very particular kind of example, then you need to tell us what exactly you are trying to do in that process. If you don't know what that process needs to do, then maybe you don't need that process to be there. Just a few examples: http://www.engineering.uiowa.edu/~digital/Common/lecnote/process_vhdl.ppt http://www.vhdl.org/vhdlsynth/vhdlexamples/ Look at class notes 2 and 5 here: http://www.echelonembedded.com/jhufpga/ And you of course have the TG68 sources, I'm sure that has plenty of this stuff in there to look at. What are you trying to do at this point? Just synthesize your accelerator_top with the TG68 inside and nothing else, and see what happens on the board? You may not need any process for just that. Reset and clock and everything come and go to the motherboard you connect to, into and out of the TG68. Why not have a reset in your accelerator_top portlist and let the motherboard drive that into TG68 like you did with clk_7MHz? |
|||
|
RE: TG68 starting problem
by majsta on Apr 11, 2012 |
majsta
Posts: 13 Joined: Jan 24, 2011 Last seen: Oct 25, 2017 |
||
|
I don't want to be an engineer because here where I live there is no point of becoming one and also there is no way you can learn those things like you can, go to seminars, attend classes or something. I told million times that there is no way that someone create anything related to electronic here in Bosnia and for any job you need 10 days I need more then half year to finish because first of all we even don't have PCB manufacturer who can assembly 2 layer board :)
Related to VHDL learning I don't understand English used for explanation of some electrical terms or something related to new technologies so it is very hard for me to describe myself some simple words or shortcuts. Ok next one I have no idea where I m going and what I want to do because there are no any single paper related to TG68 core and even I know nothing about VHDL It would be easier for me to create my own core then to use this one. Yes I started core once, accelerator worked Amiga 600 motherboard detected new CPU, some tests are done but I have no idea how I started core because i changed something and forget what I have done related to reset signal. But you gave me some ideas now and maybe tomorrow I ll check them. There are lot of problems related to active low or high states on original CPU and TG68 core, and need to solve that first or to investigate. ALVT devices are used for voltage level translation between CMOS and LVCMOS and better explanation you can find on my site. Those devices are programmed using FPGA and also there I need to investigate direction changing for bidirectional signals, I provided one solution but I have another one in mind. So today again I spend 10 hours starting this core but again nothing. When I start the core and investigate everything expect detail manual because I just want to see more people starting new projects related to amiga and without any tutorials, help, manuals or help from few people that have managed to do something we can't create anything. There are number of people who have everything but don't want to share that, even don't want to share little time to help, just talking when I finish that it will be published, and then stuck somewhere and don't want to talk about that because they need to reveal they "secret codes" or something. And that is why those things are never published and that's why is amiga going nowhere. Maybe there are some newsgroups, forums that I don't know but believe me I m searching every day for any information that can be used to finish Amiga accelerator without any previous knowledge. So I don't know what I want to create but I ll recognize that when I get there, thanks anyway, and thank you for nice support you gave me over mail... |
|||
|
RE: TG68 starting problem
by amigabill on Apr 12, 2012 |
amigabill
Posts: 34 Joined: Dec 14, 2008 Last seen: Dec 13, 2022 |
||
|
Well, please understand that this project of yours IS engineering work. To get anywhere with it, you WILL need to learn a lot about this kind of engineering. The project you have been talking about here and on other places is the point of learning it for you right now, there is a point in learning engineering. This is digital logic design and programming all mushed together. If you want to do your own processor, that's pretty complicated digital design, not something trivial. It may be difficult if technical English is hard to absorb, if this kind of information isn't available in an easier language for you then it is an effort you must make to learn anyway. If you don't, then this project isn't going to go anywhere. You don't need local assembly or manufacturing. I've seen pictures of your boards, so you obviously have some kind of solution for that. Maybe it takes a while, but it's obviously doable, and I don't consider the PCB side a problem because of those pictures.
I've pointed you to a university class website with class notes (a previous year of the class I am in now for the university I am at now), in email I've sent you the VHDL book title for this class I am taking now, which I really recommend as the next thing any money gets spent on for this project. I'll donate a bit to get you that book, perhaps try to get others to donate toward that as well, but don't buy any more chips or PCB or anything else until you have a good book, and this is one. (P. Chu RTL Hardware Design using VHDL) If not this book then a book that is a companion for an FPGA development board. Chu has a VHDL book that goes with a Xilinx development board. Chu's new SOC VHDL book goes with the Terasic DE1 board if I remember correctly. Consider an FPGA development board such as DE1 and a book that goes with it as the first things you should spend any further money on. 1. Embedded SoPC Design with Nios II Processor and VHDL Examples (DE1 or DE2 board) 2. FPGA Prototyping by VHDL Examples: Xilinx Spartan-3 Version (Spartan-3 Starter Kit board) 3. Rapid Prototyping of Digital Systems: SOPC Edition (DE1, DE2, UP1, UP2, UP3 boards) 4. RTL Hardware Design Using VHDL: Coding for Efficiency, Portability, and Scalability (not a companion to a board, but just a great book about doing RTL style design in VHDL) I'd recommend the last book there alone, and also the first Nios II book and a DE1 board to go through the example projects. Do that to learn your way around in there by following book examples and putting them into a supported board, and DE1 is probably the least expensive of these. I don't know what you would have to pay, but I can get a DE1 for US$100. The DE1 gives you other opportunities to experiment as well. Minimig already runs on it, using the same TG68 processor as you talk about here. You can learn about the TG68 by experimenting with a design that already works. Bring out signals such as dtack or whatever you suspect TG68 has backwards signal level for, and look at it to find out for sure. Substitute the Suska wf68x00 in place of TG68 and see if that makes a difference on the bus. See how the memory controller for this board works, look at the DE1 board schematics, and consider a direct copy of the memory portion there as start to your board design. And finally, the DE1 is also used in a related project I saw at EAB whre someone made an adapter board to connect DE1 to an Amiga500 68000 CPU socket, which sounds very similar to what I think you want to do. http://eab.abime.net/showthread.php?t=52364 I think he posted PCB design files somewhere. I tried to buy a finished one from him but never got an answer if they were for sale or pricing etc. Look at the SUMP open-source, goes inside the FPGA logic analyzer to help you see what signals are doing in there, both for simulation and in your board. It's not needed as much for simulation as you shoul dhave waves anyway, but you can simulate with it to debug how you insert and connect this part into everything else so you're more confident using it in your board. This saves you form having to buy expensive lab tools. http://www.sump.org/projects/analyzer/ And search the internet, there really is a lot out there on VHDL to find and learn. I've found the VHDL Cookbook in a few places, but don't like that in particular. Maybe you will. But there's a great deal of other stuff, and a lot of that is lecture slides/powerpoints for various university classes on this topic. These are just some ideas of how to learn some of what it sounds like you want to do, without taking a USA university course like I am. Get a book or two. Get a board to go with. Do projects n the book on a real board. Play around with it and see what happens. Keep asking questions. In time, you will find you ask less basic questions like what to put in a process, you will begin asking more detailed questions as you get better and get further into these and your own project. And eventually you will have something of your own working, and you can proudly demonstrate that to people who have been not supportive of your idea. Expect it to take a long time to learn what you still need to learn and then use that to make your design. Then be happy that you might be one of the few experts on VHDL RTL design and simulation in your country Bosnia. Maybe you'll enjoy teaching it to other people there someday. I don't know what FPGA software you have used so far, you may have to change to play with DE1 board if I can convince you to get one and learn with it. (If you use Xilinx ISE, you will have to change to Altera Quartus II software for this board, but it's the same idea) |
|||
|
RE: TG68 starting problem
by amigabill on Apr 12, 2012 |
amigabill
Posts: 34 Joined: Dec 14, 2008 Last seen: Dec 13, 2022 |
||
|
Also, I really recommend a subversion or other repository to track changes in your code. This would help not have problems of not knowing what you did before and something you changed since then broke it. I'm wishing I'd take my own advice here as a couple days ago I lost a file for a school assignment and had to redo fixes to a much older copy. A repository with frequent checkins is a good idea. You can do that on the same PC that you run the FPGA software, you don't need anything fancy, and it's free. Or, if you plan to eventually upload the project here to opencores, then just do it here now and use their repository here. For myself, I hope to set up a Redmine server at home, which is a multiple project managment platform much like OpenCores and Sourceforge are as a whole, with much more than just a repository.
|
|||
|
RE: TG68 starting problem
by amigabill on Apr 12, 2012 |
amigabill
Posts: 34 Joined: Dec 14, 2008 Last seen: Dec 13, 2022 |
||
|
If you're trying to figure out what to do with clock and reset for simulation, here's some thoughts:
Have a process in your testbench architecture that creates a clock signal. Here's something to get ideas from. I don't know if I have syntax exactly correct everywhere, I'm winging it. entity testbench_accelerator is --testbench does not have any ports end testbench_accelerator; architecture testbench of testbench_accelerator is signal tb_clock_7MHz : STD_LOGIC; --system clock into accelerator_top signal tb_reset : STD_LOGIC; --system reset into accelerator_top signal s_num_errors : integer; --signal version of number of errors count --so we can see it in waveforms ... begin --instantiate accelerator_top i_accelerator_top accelerator_top ... --68000 bus signals out of accelerator_top ... accelerator_top_reset => tb_reset, accelerator_top_clk_7MHz => tb_clock_7MHz, --voltage level shifter signals ... -- ... --this process creates a freerunning clock for simulation p_clockgen: process() constant TB_CLK_PERIOD : time := 143 ns; --143 nanosecond period is about 7MHz frequency constant TB_CLK_PERIOD_HALF : time := TB_CLK_PERIOD / 2; --each clock phase is half a period begin tb_clock_7MHz wait for TB_CLK_PERIOD_HALF; --0 for half a period tb_clock_7MHz wait for TB_CLK_PERIOD_HALF; --1 for half a period --loop back to top of this process forever end process p_clockgen; p_stimulus: process() v_num_errors : integer; --variable for number of errors --Xilinx iSim simulator cannot display waves/values --for variables, so assign this to a signal when we --change this so we can see it happen in waveforms. --(I'm using iSim for the class I'm in right now, --and I don't know ModelSim etc.) begin --initialize testbench things here before we get started v_num_errors := 0; --haven't even checked for any yet, have not found any yet --load boot ROM or RAM etc. from compiled 68000 binary data file --simulation starts here and things happen until end of this process tb_reset wait for 5 us; --wait a while for reset to take effect and set registers --to their desired starting values tb_reset --do other controls here to make simulation do what you want. --this might be a lot of things, or it may be very little. --you'll have to decide what you want to see happen in simulation --and work and ask questions to make all that happen here. --maybe check that accelerator_top does what it needs to do to --disable the motherboard 68000 CPU so that accelerator_top's TG68 --(or acclerator_top's wf68k00 etc) take over properly --maybe let things run for a while and then cause a new reset --maybe have some motherboard chip take over the bus to --do a DMA, accelerator_top has to wait for that to complete. --maybe cause a bus error and see if accelerator_top behaves correctly for that ... assert (v_num_errors = 0) --we want number of errors to be = 0 here report "FAIL - Errors were found during simulation!!!" --report is displayed if the condition next to assert above is NOT true, --meaning it is displayed if v_num_errors is not = 0 anymore. severity FAILURE; --simulation tests fail, something went wrong. --I have something a little more complicated for my current class project at home --which can display how many errors happened by the end of simulation, --but I can't remember now as it uses a long ugly chain of typecasts. --I copied it from the internet somewhere. assert (v_num_errors /= 0) report "PASS, no errors were detected" --this time, report is displayed if v_num_errors IS = 0, --which is what we want to happen. --I find it confusing that report happens when --the opposite of the condition is true, but that's how this works. severity NOTE; wait ; --wait at end of simulation forever. Something somewhere should --cause completion, an assert for example. end process p_stimulus; --this process watches the 68000 bus outputs from accelerator_top and --records events to a text log file. You might put another process --very similar to this inside accelerator_top to spy on things inside there --which we cannot observe directly out here in testbench, for intereting --things which are not accelerator_top ports. --I can't do exact code here as my things doing this sort of thing are not --with me at the moment. I copied from examples on the net to get --what I have at home, you should be able to figure out the same things too p_spy_68000: process(interesting 68000 bus signals out of accelerator_top) --output text file --outline --line of text to write to file begin --record to text file what the accelerator_top 68000 bus signals are doing --these can also be seen in waveforms, but a textfile format might --also be useful, with timestamp of each new value --maybe also have some asserts in here to test for correctness of 68000 bus events end process p_spy_68000; --more processes can spy on other signals or busses if needed. end testbench; |
|||
|
RE: TG68 starting problem
by amigabill on Apr 12, 2012 |
amigabill
Posts: 34 Joined: Dec 14, 2008 Last seen: Dec 13, 2022 |
||
|
Some hungry monster ate my indentation up there. Sorry. :/
|
|||
|
RE: TG68 starting problem
by majsta on Apr 13, 2012 |
majsta
Posts: 13 Joined: Jan 24, 2011 Last seen: Oct 25, 2017 |
||
|
Hm yes there are some interesting stuff there. Again all day worked on this and again nothing, but find number of problems and solved them so we will see tomorrow...
|
|||
|
RE: TG68 starting problem
by amigabill on Apr 16, 2012 |
amigabill
Posts: 34 Joined: Dec 14, 2008 Last seen: Dec 13, 2022 |
||
|
Hm yes there are some interesting stuff there. Again all day worked on this and again nothing, but find number of problems and solved them so we will see tomorrow...
Ugh, 5th or 6th attempt to reply again. I don't intend to do much more opencores talk on my Android phone again, it's a horrible experience that doesn't make it at all convenient to recover from a mistake. (such as posting but forgot to login first, or accidentally doing a previous page, there does not seem to be a good back to bext page thing in the Dolphin browser, etc., and forgetting that I have to submit twice to actually get posted, I often think the first submit to preview is the final post) What were you attempting to do that instead was a nothing for the day? It's hard for us to help you if we don't know what your particular goals are. While I've talked a lot about simulation, I don't know if you're trying to do any simulations or if I'm being helpful there. For the next day that you work on this, what do you plan/hope to have done at the end of the day? (please answer so we can get an idea of what you think every day) I'll try to suggest a couple small goals for you. It may take some days, that's OK. 1a. It seems you suspect that TG68 has some 68000 bus signals inverted. before going further with the overall design, find out for certain if this is true or not. Put TG68 in a simulation testbench and see what it does for the first bus cycle. Even without a RAM or ROM present, TG68 should try to talk to something, and then have a problem when there is no answer. But this attempt to talk to something should give you an idea what at least some of the TG68 bus looks like in waveforms. Something similar to the testbench I posted above should be enough for this. I don't know if that will use all the signals you suspect are inverted or if it will miss some, but it's a start. 1b. Compare minimig-original (with real-life hard 68000 chip on PCB next to FPGA) with the DE1 port of minimig (which uses tg68) and see if they had to make changes to minimig to fit the TG68 properly. What do you try and achieve or complete each day? A simulation? A synthesis? Putting a bitfile into your board and see if it does something good? Try to think of a small goal each day you work on this, maybe a goal over a few days or a week. Don't try to have everything working on your board in a day, that is way too much to succeed while you learn how to do these things. |
|||
|
RE: TG68 starting problem
by amigabill on Apr 16, 2012 |
amigabill
Posts: 34 Joined: Dec 14, 2008 Last seen: Dec 13, 2022 |
||
|
1a. It seems you suspect that TG68 has some 68000 bus signals inverted. before going further with the overall design, find out for certain if this is true or not. Put TG68 in a simulation testbench and see what it does for the first bus cycle. Even without a RAM or ROM present, TG68 should try to talk to something, and then have a problem when there is no answer. But this attempt to talk to something should give you an idea what at least some of the TG68 bus looks like in waveforms. Something similar to the testbench I posted above should be enough for this. I don't know if that will use all the signals you suspect are inverted or if it will miss some, but it's a start.
And if you do that, then swap the TG68 in this testbench for the suska project's wf68k00 and run the same simulation, and see if that looks the same or different. |
|||
|
RE: TG68 starting problem
by amigabill on Apr 17, 2012 |
amigabill
Posts: 34 Joined: Dec 14, 2008 Last seen: Dec 13, 2022 |
||
|
Hm yes there are some interesting stuff there. Again all day worked on this and again nothing, but find number of problems and solved them so we will see tomorrow...
More things to help us help you: What is interesting, and what is not? Why? Also, what is useful, and what is not? Why? Just trying to get a better idea of what's useful to you so we can try to focus on those things, and perhaps to suggest things should be useful when they might not seem that way yet. |
|||

1/3 
