Thanks!

Anyway, i had the idea to have a 4 bit data bus, and a 8 bit address bus, but it is still a bit unclear how will the instruction word look like. It would be good if it would be 12 bit long, 4 bit instruction, 8 bit data, but this would take too much space. If it would be 8 bit long, then the first 4 bits would be the instruction, and the other four bits would be address. For addressing all of the 256 locations, pointers might be used, like in risc processors(where you can address only a part of the memory). But then again how would be the simplest way to use pointers.
Anyway, how could i put this project on github,so that other people can be involved also(somebody from this community, if anybody is interested).

What would be the simplest schematic for a 8 bit program counter circuit?

Can't give you a schematic. How about some 8bit counter ICs?

74AS869
74F269

They used to be available a year or 2 ago.

How to make a 2 phase non overlapping clock generator in vhdl?

I have a (VHDL) register array 4x4:
type reg_array is array (0 to 3) of integer range 3 downto 0;
variable Reg : reg_array;

Now i want to address it with a bit_vector(in my case IR(3 downto 2), ect...) value, but i can't find a way to convert it to integer.

I solved it by turning everything in std_logic_vector.
But i am having issues with the 2 phase clock, when i try to detect the falling and rising edge i get unsupported Clock statement.

Dajgoro:

The pace of your investigations just makes me me tired. Keep up the good work.

Two comments on your post.

First, you will require separate rising and falling edge triggered FFs. It is not physically realizable in a single FF, so VHDL (and most standard HDLs) will require you to separate the rising and falling edge FFs into separate clocked processes.

Second, I have seen some discussions on this forum regarding the use of AFTER statements to introduce physical delays in the synthesized RTL. It appears that this is driven by a desire to utilize the programmable delay lines found on the inputs of most advanced FPGA I/O blocks. As said elesewhere (check out Arlet's responses), the VHDL 'AFTER' and Verilog '#delay' constructs are not synthesizable; they are strictly simulation statements only.

In contravention to the opinions of many, I use these statements in all of my code to reduce errors with behavioral simulators. Generally speaking the simulator ought to be able to resolve, i.e. properly separate input signal transitions and output signal transitions, but some simulators have problems with two many transitions in a 'delta' cycle, the fundamental internal cycle of the simulator (similar in nature to one of the sub-steps of a Runge-Kutta integrator). Therefore, they either fail to converge or they issue an error or warning.

Because there is nothing actually wrong with the HDL, a significant amount of time can be wasted in tracking down the reported problem. To get around this, I use AFTER 1 ns (VHDL) and/or #1 (Verilog) to artificially delay the output transitions of FFs until the next simulator evaluation cycle. This technique has proven to be a good approach and generally portable between ISim, ModelSim XE and Altera, Mentor Questa, etc. It does, however, require a certain level of OCD (Obsessive Compulsive Disorder) to make all the FF outputs include the statements.

All that being said, I never loose sight of the fact that internal circuit delays are not something that can be controlled in FPGAs. If significant delays are required, for whatever reasons, I will use an unused (or unbonded) I/O buffer. The synthesizer and router will generally route the signal to and from the I/O, and will not rip it out and optimize the route path since it can't know what the external load might be. This is particularly true is a signal is routed to an output with an externally controlled output enable signal. In this case, the synthesizer and router can make no assumptions regarding the loop-backed input signal: whether it's a simple loopback, or whether it is a completely independent input signal from an external source.

Although I make use of the programmable input delay lines and the corresponding training logic for interfaces such as DDR2 memory interfaces, those features can not generally be inferred by most HDL synthesizers. There may be special semantics that may infer those delay structures, but I've not run across them.

In general, it is not good RTL practice to rely on delay statements to achieve correct behavior. Instead, to achieve a non-overlapped multi-phase output, like it appears you want, you would be more likely of success if you used over-clocked shift registers with the clock being used to determine the delay between the two phases.

_________________
Michael A.

Thanks for the reply. This is my first VHDL project that is not a homework or a lab exercise.
I intend to use a CPLD(XC9572), since the fpga is volatile, and i want a permanent device that runs on 5V, but i don't want to invest much $ in this project, so i stick with smaller cpld.
Ill try to separate the code into 2 process blocks, each for a clock phase, i could also make an external 2 phase generator, so ill save a few macrocells.
I am still waiting for my lpt jtag, actually i already bought the parts to build it myself, but then i decided to give that few $ and save myself many hours of debugging the diy jtag.

Dajgoro:

Separating them into separate processes is required, but will not guarantee a non-overlapping clock structure. Generally two phase system are used to compensate for internal signal path delays in the physical circuit, and require a non-overlapping waveform to operate correctly. Such a clock generator will likely require an analog comparator with voltage thresholds set higher than normal so that the pulses representing the two phases are guaranteed to not overlapped.

When two phase systems were popular, the internal routing and gating delays were large. Thus, one phase was used to gate (using latches rather than registers) signals onto an output bus (say the address bus), and the other phase used to complete the cycle. The transparent nature of latches added to the overall delay from the register to the address pins, but would allow the address to be presented earlier and held for a longer period of time. This allowed lower operating clock frequencies to be used, which with CMOS logic results in lower dynamic power dissipation. The second phase is essentially a delayed version of the first phase and allowed the devices to complete the desired transaction in the same cycle. Essentially, half of the device operated on one phase and the other half on the other phase. A delay between the falling edge of the first phase and the rising edge of the second phase is generally required to ensure the two signal do not overlap.

You can simulate that behavior with a 2x system clock and using complementary clock enables to emulate the first and second phases. There is some additonal differential power dissipated in the 2x clock distribution amplifiers, but the complementary clock enables only allow half of the design to change state at a time. Thus, a system using complementary clock enables will exhibit power reductions similar to a system using a two phase clock, but in a manner much more consistent with modern design practices.

I don't write to discourage your efforts, but you do appear eager to investigate a wide variety of topics, and power management should also be a consideration. Correct implementation of a two-phase, non-overlapped clock driver that operates when critical parameters vary (frequency, temperature, voltage, capacitive loading, etc.) is challenging.

_________________
Michael A.

I already built a entire system around my 6502 sbc. Actually i have a sbc that can operate by itself, but later i added the backplane, and on it i have the crtc module, and other stuff. So the idea is to have an exchangeable cpu board, so that is another reason why i want this to be bus compatible with the 6502.

I am just hoping that it will all fit in toes few macrocells...

The CPU is almost completed, but i already ran out of macrocells.
It seems that instead of making an big alu, the synthesizer made a full adder, subtracter, ect... for each case of the instruction decoding.
I was trying to make the alu in another file, and then use it in the cpu, but it seems i can't use it inside process blocks. If i put it outside then i need to use signals, but then how will it get all synced, its a mess!
I also tried with functions, but then i got zillions of errors while trying to make it use std_logic_vector instead of the integer, as in the example that i found...
How could i describe the alu in one place, and then just use it elsewhere?

Besides the 9572 there is the 95108 which has more macrocells.

For your ALU problem, you could "resuse" the same adder for substraction by doing the 1s complement and inverting the carry into a borrow (like the 6502 does)
Your comment seems to imply that you get an adder _and_ a substractor, so putting a switchable inverter into one of the input is an option to remove the substractor.

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

I have the 108 too, but i reserved it for the graphic project, and they are quite expensive, i got if for less, but now it is 29$+shipping on ebay...


I have the schematic for a compact alu already, i minimized it to the max using the Espresso algorithm.
But i can always rewrite it in vhdl.
My issue it that i don't know how to connect an component inside a process, or something like that.

Here is the project, and what i managed to do so far:
http://betaic.com/SW5000/
I still haven't found a way to make a compact alu.

Any suggestions/comments are welcomed, since i am not an expert in VHDL.


Edit:
there are:
16 bits for registers
8 bit instruction register
8 bit program counter
8 bit full adder/alu(only 4bit)
That is a total of 40 macrocells.
Everliving else is glue logic, state machine (2 states) and instruction decoding)

When i scrapped the program counter increment circuit, and patched it trough the alu, it used even more macrocells than before. When do some small changes in the code, that don't make a difference i can get very different results in macrocell consumption. Usually i stick around 80, i even got down to 78, but now i am back to 86, and sometimes i get over 130...

BigEd suggested that i should post the block diagram (sketch) that is available in that link i posted before.


The list of instruction: