MichaelM wrote:
The original design utilizes a Programmable Logic Array (PLA) to implement the control logic. Defining the operation of a processor using a PLA is similar to implementing it using microprogramming except the logic requirements are much less with a PLA. Unfortunately, modern FPGAs do not implement the logic structure of a PLA. Some modern Complex Programmable Logic Devices (CPLDs) provide the necessary AND-OR logic arrays to simulate the logic structure of a PLA, but modern HDLs like Verilog and VHDL do not easily support the PLA logic structure.
I thought PLAs were the same as PLDs such as the Lattice ips1048 PLD that the MiniForth was built on --- IIRC, that had AND and XOR rather than AND and OR.
I never heard of CPLDs --- I thought PLD technology was obsolete and everybody used FPGAs now.
Anyway, I don't know enough about that level of design to really comment on the subject.
MichaelM wrote:
On several occasions I have opted to use the soft-core processor from my FPGA vendor of choice: the Xilinx Microblaze 32-bit soft-core processor. And several times Xilinx has obsoleted my designs by updating the processor core itself and the I/O structure it uses to access the FPGA resources. Of course it is possible to rebuild the Xilinx components to use the updated specifications, but all of my custom designed components would have to be changed to connect to the new processor core and I/O standard.
I remember in 1994 that a lot of electrical engineers were mad at Motorola because Motorola kept coming out with a latest/greatest processor, and abandoning the users of their previous processors --- just tell their customers: "Well, rewrite your program!"
For example, the 6811 obsoleted the 6809 --- a lot of people liked the 6809 though, and there was quite a lot of 6809 software in use --- nobody liked being told to rewrite all of the 6809 software!
Because of this, a lot of people switched to the 8051-family --- the 8051 was arguably not as good technically as the Motorola chips, but it had the advantage that the users wouldn't get the rug pulled out from under them.
Later on, Motorola dropped out of the processor business --- their latest/greatest was ignored, and the 8051 is still used today --- so, apparently it is not a good idea to repeatedly pull the rug out from under your customers!
MichaelM wrote:
I am not developing the M65C02A other than for my satisfaction. Part of the process has illuminated a variety of trade offs to me. In that sense, the M65C02A has been as much a project for my personal enjoyment as it is a project for studying various implementation approaches.
Having your own soft-core processor that you like is worthwhile --- you can get good at it --- you don't have to spend time learning somebody else's design, or accept somebody else's design decisions.
Also, there is the security issue. In 1994 at Testra they developed the MiniForth processor --- one reason they did this, rather than use a commercially available processor (I suggested the MC6812), is that Red China wouldn't be able to steal their motion-control board software --- their greatest fear was that somebody would come out with a motion-control board at half the cost that runs Testra's software and is stamped: "Made in China."
I don't think this is possible now though. In 1994 Testra could implement a processor on the Lattice isp1048 PLD, and nobody else could --- Testra had their own HDL --- everybody else was using LDL (Lattice Design Language) from Lattice that was inadequate.
Now everybody uses Verilog or VHDL --- it is no longer possible to write your own HDL because the internal details of the FPGA are not available --- that is what I was told.
Realistically, any HDL programmer could produce a TOYF given the specs. My plan is to not tell anybody what the opcode map is, and not give away the source-code to my assembler. They would have to figure this out for themselves by looking at the machine-code and comparing it to the source-code that generated it. This is more difficult than it seems! Both group-A and group-B have two undefined instructions. I can define these as NOP instructions, so I have 3 NOP instructions in each group, and have the assembler randomly choose which NOP to use when a NOP is needed. This is going to seriously complicate figuring out what the opcode map is! It is still possible, but it will take quite a while.
MichaelM wrote:
Finally, I am not trying hard to get the M65C02A accepted as commercially available silicon. I expect to use the core in products that I produce for my company or that I develop for others that can make use of its capabilities in a cost-effective manner.
Well, I'm expecting the TOYF to out-perform the MSP430, and to be less expensive --- the MSP430 is pretty much the leader in the 16-bit world.
I am interested in your M65c02A though. It might use a lower-cost FPGA than the TOYF --- that would make it especially interesting!
I don't think it is going to compare well in speed, but blazing speed is not always needed --- low cost is always needed!
Can you comment on the cost of the FPGA used by the M65c02A as compared to what would be required for an MSP430 soft-core? The M65c02A has fewer registers, and it has fewer instructions, and it is 8-bit rather than 16-bit, so I would expect the M65c02A to use a pretty inexpensive FPGA as compared to most other designs.
BTW: What do you think of the Parallax Propeller? That is an example of somebody coming out with his own processor and getting it accepted as commercially viable --- it is not taking the world by storm --- it is making a profit though.
If my TOYF were as successful as the Parallax Propeller, I would be pretty happy!
I have group-A group-B and group-M instructions executing in parallel --- that is pretty
I think --- by comparison, the Propeller has 8 processors running in parallel, but they each have their own memory, which is pretty complicated.
I would actually expect your M65c02A to be more efficient than the Parallax Propeller --- you have a lot of support for high-level languages --- the Propeller ISA seemed kind of prickly and hard-to-use, from what I gathered from the documentation, so even with 8 processors running in parallel, it might still be slower than the M65c02A assuming that the M65c02A Forth has minimal ISR entrance and exit code.
Login
Register
FAQ
Search
