You can use mine as a starter :)

But I'm busy writing a text that could fit into your and other peoples plans. See my own thread.

_________________

As I am currently busy with my job, before it starts to rot on my harddrive, I'm publishing a small update on the 65k project

http://www.6502.org/users/andre/65k/index.html

I've updated the programming specs with folding special registers with special opcodes into the control register file (which reduces the number of special opcodes), and the reworked interrupt, trap and abort handling (esp. the vector definitions)

I've also updated the architecture with some data path analysis for the different addressing modes and some (not all yet) opcodes.

André

I've updated the specs again. Some reordering of opcodes, most importantly another prefix bit (EE) added. Now you can fetch an 8-bit value from memory, automatically expand it to full register size, and use it in a full-size operation.
http://www.6502.org/users/andre/65k/index.html

* WAI becomes privileged
* Moved no-operand opcodes in EXT page from column $f to $8, to be more aligned with standard opcode page
* Added the INV opcode for the 2s-complement
* Moved SWP to the EXT page, reordered the prefix codes
* reordered the EXT column $8 and $a codes
* Removed the INE/INB/DEE/DEB quick opcodes, added SLX/SRX/SLY/SRY quick opcodes instead
* Reordered opcode column $f, so all non-prefix opcodes have addressing mode abs,X
* removed NOP zp/abs, moved STX abs,Y to previous NOP abs location
* Cleaned up duplicate opcodes for AM=1, clarified table description
* Changed the BSR prefix usage definition to one similar to JSR, which removes the need for one of the BSR duplicate opcodes
* Added the EE "early extension" prefix flag
* reordered some EXT codes
* Added the stack peek opcodes PKA, PKX, PKY
* Added the EXT and CUT opcodes
* Added the Accumulator addressing modes for ADE/ADB/ADS/SBE/SBB/SBS

Admittedly the stack peek opcodes will already go away, as there is an equivalent with the "LDA S,$01" opcode.

André

I've started to get more serious with the design: I started putting the CPU definition into an XML file, including assembler syntax, addressing modes, prefix bits etc. I am currently writing some code to create the documentation from that XML, which will then replace the currently manually maintained docs on the web site. I already found some missing opcodes (where I forgot to add the "(E)" addressing mode to some operations) and even an opcode I had in the table twice, just with some simple validation, so that's a good thing.

Next steps will be update the CPU architecture (which I already have in my mind...), and generate some decoding logic from the XML file.

One question there: anyone knows how good the ISE WebPack optimizes logic equations?

For example, to decode when a specific addressing mode or opcode is used, I could basically enter the full opcode table, hoping that ISE would eliminate the irrelevant terms. Or I could optimize the equations outside VHDL (e.g. with a quine-mcclusky algorithm, that I've once written to find the equations for the 8296 PLA... http://en.wikipedia.org/wiki/Quine%E2%8 ... _algorithm ) and simply enter the optimized equations into VHDL.

My hope is that optimizing the equations outside ISE will give me food for more optimizations, like rearrranging the opcode table (for the new opcodes) - but is this really relevant in a VHDL design?

Any ideas?

Thanks in advance
André

Edit: the plan is also to create an assembler from that XML file... This might even be ready before the actual CPU...

Andre, I think most of the HDL experts here seem to be favoring Verilog, but to answer your question: (as far as my limited experience with HDL is concerned)

ISE has been made by some serious math experts, it is an optimizing beast. Rest assured it will do everything possible to put Xilinx IC's at the top of the game. You can change settings to optimize for speed, area, power. I've seen ISE optimize my hardware design based on what I have written in software for the BRAM's (internal ROM's). It will trim everything not used internally, unless it is tied to a pad... I thought I had some simple OR gates and ISE makes a LUT out of them!

Hmm, I'd express a more cautious view. Arlet's core has a register file which is implemented efficiently as a RAM, but a small coding change caused it to be implemented less efficiently. At least some of the implementation choices seem to be done by pattern matching, so if you don't quite make the right pattern, you don't get the good result.

More generally, the solution space is enormous and the tool can't explore it exhaustively: I think it's still true that a good HDL engineer can get a better result than an average one (I've worked with good ones) and indeed a better result than tools which convert C or other HLL to hardware.

I don't think the synthesis is going to be magical - it's going to be OK, and for small clusters of logic it will see things which we can't. For large optimisation problems - like finding the known bitfields in 6502 opcodes - I don't think it will get close to a carefully expressed design.

(There's a bit of opinion and speculation in there.)

Cheers
Ed

I think there's a difference between generic logic equations, and trying the tool to recognize special features of the FPGA, such as memories, shift registers, muxes, carry chains, and multipliers.

For normal logic equations, I think the tools are pretty good, and there is little sense in trying to optimize it yourself. Also, because of the FPGA fabric, different rules apply. On a Spartan-3, you have 4-input LUTs, which can evaluate any 4-input (or less) logic function. On the Spartan-6, you get 6-input LUTs, which means that a 2-input OR function takes exactly the same amount of resources as a 6-bit comparator with a constant.

A good strategy is to try and minimize the number of inputs in the logic equation, for example, by careful design of the instruction encoding, and let the tools figure out the rest. It's also good to realize that in an FPGA, flip flops are abundant. Keeping intermediate results in flip flops helps to get faster designs.

Nothing is perfect... This is an interesting read on the Xilinx Forums, recently, involving the Spartan 6 and the new ISE 13.1 ISE software.

Although it is for a very particular situation of Flip-Flop timing, problems remain in the simulation even to the newest release...

Just to give you a heads up...

I've been busy with other stuff last year, so I haven't progressed as far as I had hoped with the 65k...

However, I have now updated the programming spec - fixing bugs, rearranging/adding/obsoleting opcodes on the way... http://www.6502.org/users/andre/65k/specsprog.html

I clarified the interrupt handling a bit. If it boots up, it will use the 6502-compatible interrupt vectors. This allows it to boot up in an otherwise pure 6502 system. I might add a hardware option to read them from $fffffffffffffe or $000000000000fffe (I love writing 64bit addresses in the 6502 context :-) I still have to clarify how SEI/CLI work in that respect. So far it states they are privileged operations, have to verify that...

The opcode tables have been replaced with tables generated from an XML file I will also use to generate the VHDL opcode decoding code, and also code for the (planned) 65k cross assembler. So the first step is done to fully do the opcode decoding. In the current VHDL (which hasn't changed for over half a year now :-( it boots and runs a few cycles, but only hand-written opcode decoding for those few cycles... But when that is done and it runs some more cycles, I'll put it up on github....

André

Just a heads up for now. I've been working some time on my 65k core and it's progressing well.

I've made a "smoke test" with some selected operations and addressing modes, and it looks good so far.

The "only" real thing missing is the interrupt and abort handling, but I'm confident that this can be (relatively) easily implemented (as pseudo-opcodes similar to the 6502 and the 65k RESET handling), and handling mixed-width environments (reading word values from byte-wide memory etc).

Then add some docs, copyright notices, and put it up to github :-)

So stay tuned, should not be long now...

André

Good to hear it! Are you running in simulation as you go, or on hardware?

Unfortunately I am running in simulation only so far. I know there are many with working FPGA setups out there already, so I want to get to publishing it first.

But my plans include to build something like a "pet65k" board next, using a GODIL on one side (at least in the first version), 16bit RAM, some I/O and a connector to a 6502 socket.

André

The first public code release is there! Please discuss it in the other thread here: viewtopic.php?p=18552#18552

André

Just a heads up - I have a Xilinx Spartan running a 6502 core (T65 or RB65), and "almost" booting on my selfbuilt computer which I basically plugged it in...
So over the next week I expect to do the first debug session on real hardware, not just simulation.

Also I am looking into rewriting the af65002 in a much smaller version, with 8bit data bus only for a more simple start...

_________________
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/

Very cool! Which Spartan family, what part #?

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502