6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 24, 2024 2:47 am

All times are UTC




Post new topic Reply to topic  [ 11 posts ] 
Author Message
 Post subject: MOS 6502 on Verilog
PostPosted: Sun Nov 16, 2014 3:03 pm 
Offline
User avatar

Joined: Fri Jun 22, 2012 7:39 am
Posts: 201
I decided to start new topic, since I moving on another level (hardware related).

I'm going to reimplement 6502 on Verilog from reverse engineered circuits, according to this topic : Breaking 6502 apart

I set a goal to make it synthesizable code.

But I have low practice on Verilog programming :) Can you please guide me until I gain experience? :)

Today I started on Interrupt Control circuit. It is simple enough to learn Verilog syntax.
I used Icarus Verilog to compile it.

Can you please give some comments, if anything is wrong here.


Attachments:
INT.png
INT.png [ 58.27 KiB | Viewed 2731 times ]
InterruptControl.txt [3.42 KiB]
Downloaded 187 times

_________________
6502 addict
Top
 Profile  
Reply with quote  
 Post subject: Re: MOS 6502 on Verilog
PostPosted: Sun Nov 16, 2014 8:39 pm 
Offline
User avatar

Joined: Mon Apr 23, 2012 12:28 am
Posts: 760
Location: Huntsville, AL
org:

There are a number of technology based reasons why the 6502 used latches in its implementation. Both Verilog and VHDL allow the declaration and use of latches. The synthesizers will issue warnings for all latches found in a design regardless of whether they are explicitly defined or implied as may occur when incomplete decision statements are used in a design.

The primary reason that modern synthesizers behave in this manner is that using latches makes it particularly difficult for the synthesizers and place and route tools to control timing. There's also a misconception that delays embedded in HDL statements are realizable, and that is not correct at all. Another misconception is to add "gate components" from the libraries, such as inverters, to introduce delays along particular signal distribution paths. With few exceptions such as components embedded in the silicon of the target device, "gate components" from the libraries are virtual components which the synthesizers and place and route tools strip or add as needed to a design; stringing such components together in a chain will have no more of effect than placing just one in the design.

My recommendation to you is to adopt a edge-triggered register design approach. When using latches as you have, standard simulators will likely provide the correct results during simulation of the circuit, but the resulting synthesized, placed, and routed design is very likely to not behave in accordance to the simulation.

That being said, I looked at your code and I would make one recommendation regarding your coding style for combinatorial always blocks and that is to declare the sensitivity list as always @* or always @(*) instead of using the deprecated approach that you used. The * operator in the recommended approach informs the simulator to figure out what signals need to be monitored. The deprecated approach, which is retained for backwards compatibility, requires you to determine for the simulator which signals you want it to monitor. If you leave out a signal, you may get a warning from some simulators that the sensitivity list is incomplete, but in any case, any signal not included in the sensitivity will not be monitored. The transitions of any unmonitored signals will not be included in the simulation of the particular combinatorial circuit being simulated. The resulting simulation never matches the circuit described by the always block.

You also used a #10 delay statement to introduce a delay between the interrupt signals being captured by Phi2 and Phi2. As I said above, delay statements are not synthesizable and although your simulator will indicate correct operation of your circuit, it is highly unlikely that the circuit in your target will behave in a manner consistent with your simulation.

I liberally use the #1 delay statement in my synthesizable code. This is not because I expect it to be included in the target, but to correct a problem that I've determined exists with many simulators. Many simulators exhibit erroneous behavior when too many signals transition at the same time. The result is incorrect behavior of the simulated circuit. I've chased my tail many times trying to reconcile what appears to be correct HDL code and the waveform being displayed by the simulator. Since adopting this coding style, I've not experienced that problem with Xilinx's ISim or ModelSim Xilinx Edition; I found both of these simulators to exhibit the same problem, with ISim being more susceptible.

_________________
Michael A.


Top
 Profile  
Reply with quote  
 Post subject: Re: MOS 6502 on Verilog
PostPosted: Sun Nov 16, 2014 9:22 pm 
Offline
User avatar

Joined: Fri Jun 22, 2012 7:39 am
Posts: 201
Quote:
That being said, I looked at your code and I would make one recommendation regarding your coding style for combinatorial always blocks and that is to declare the sensitivity list as always @* or always @(*)

I totally forgot about it :) Thanks for remind.

Quote:
You also used a #10 delay statement...

I know, this is bogus) I just used some number, to suppress Icarus Verilog errors.

Thanks again, for such detailed reply.

Concerning Phi1/Phi2 and edge-triggered implementation.

I know Phi1/Phi2 use special timing to not overlap eachother:

Image

But which approach do you recommend to replace level-triggered latches by edge-triggered?

This one?
Image

Or this?
Image

I also finished the ALU :) (See attach)


Attachments:
ALU.txt [6.14 KiB]
Downloaded 135 times

_________________
6502 addict
Top
 Profile  
Reply with quote  
 Post subject: Re: MOS 6502 on Verilog
PostPosted: Sun Nov 16, 2014 10:51 pm 
Offline
User avatar

Joined: Mon Apr 23, 2012 12:28 am
Posts: 760
Location: Huntsville, AL
org:

How you approach your project depends very much on your personal objectives for the project. You've spent a considerable amount of time studying the circuitry of the original 6502. In my opinion, it uses a non-overlapping two phase clock in order to use the latches in its design. I personally appreciate very much the solution that the design team applied. Using their latch based design approach, they were able to achieve an all around efficient implementation and deliver high performance with low clock rates; their design should be required for study by all chip designers.

Myself and others (Arlet Ottens, Rob Finch, BigEd/ElEctricEyE, Jens Gutschmidt, etc.) have all implemented various flavors of a 6502 FPGA core. Each solution is different. I like mine, but I also have great appreciation for those of the others I've mentioned. Most of us implemented our cores for the purpose of learning the processor, learning the HDL used to implement it, etc.

In providing my comments to you, I don't want to discourage you from taking whatever approach you want to take. I think there are many ways to implement a processor such as the 6502, and whatever approach you use will be best for you.

After all that, if you want to make use of the inherent concepts of the 6502 in your implementation, then I would recommend that you use the basic cycle divisions in the 6502. That is, the address is generally calculated during the Phi1 high phase, and the memory is read/written during the Phi2 high phase. Generating non-overlapping clocks like Phi1 and Phi2 can be done using a 2x clock. If strict adherence to non-overlapping clock is relaxed somewhat, then it is possible to use a single phase clock and use the first half to correspond to Phi1, and the second half to correspond to Phi2.

Under these conditions, I would use the falling edge of the clock to register the output of the address generator and the rising edge of the clock to register the data read from memory. To create a RnW signal valid during Phi2 high, I would use a DDR output register. This view of the clocking corresponds roughly to using the falling edge of both Phi1 (end of the address computation phase) and Phi2 (end of the memory access phase). (Note: I provided one of these as an example for enso about a year ago for his CHOCHI project. When you're ready to tackle the I/O off your FPGA, let me know if you'd like a copy.)

As to the ALU model that you provided, I will comment on one thing. The real 6502 uses a number of techniques based on the technology of the time. One of these is the pre-charging of buses and the transference of signals from its storage latches onto the bus using pass gates. This feature of the 6502 cannot be implemented in any way on a modern FPGA. Except at the boundaries of the FPGA, i.e. the output drivers, Xilinx (and I suspect most other FPGA vendors) have long since eliminated any tri-state drivers in the FPGA fabric. Although you use a tri-state bus driver in your model to model the 6502 buses, this construct is only available in a simulator. The circuits in an FPGA itself cannot implement such a function. The synthesizers recognize the construct and implement the bus as a wired-OR (default to logic 0) or a wired-AND (default to logic 1) bus using standard totem-pole logic. Thus, when you get to synthesis, you may get an error message such as "multiple drivers found on xxx".

As I said above, I don't want to discourage your efforts, but I also want you to be aware of what I think may be some misconceptions regarding FPGAs. Unlike a chip implemented using a silicon compiler, like those used to create FPGAs, a synthesizer targeting an FPGA must use only the circuits already implemented in the silicon of the FPGA. Thus, any designs targeting an FPGA must be acutely aware of the capabilities built into the silicon of the device. Verilog and VHDL are hardware description languages, and as such the primary focus for these languages has been hardware modeling not hardware design. They support a broad range of hardware modeling activities, and not all simulation models can be targeted to an existing device like an FPGA. Therefore, I suggest getting out the data sheet and user guides of the Spartan 3 and Spartan 6 FPGAs (or the Altera Cyclone FPGAs) to get a clearer understanding of the capabilities of the silicon itself.

_________________
Michael A.


Top
 Profile  
Reply with quote  
 Post subject: Re: MOS 6502 on Verilog
PostPosted: Mon Nov 17, 2014 5:28 pm 
Offline
User avatar

Joined: Fri Jun 22, 2012 7:39 am
Posts: 201
Tried to compile it in Cactus II, everything looks good :D At least it compiled and fitted it without errors.


Attachments:
InterruptControl_RTL.png
InterruptControl_RTL.png [ 58.38 KiB | Viewed 2663 times ]
Core6502_RTL.png
Core6502_RTL.png [ 18.85 KiB | Viewed 2663 times ]

_________________
6502 addict
Top
 Profile  
Reply with quote  
 Post subject: Re: MOS 6502 on Verilog
PostPosted: Mon Nov 17, 2014 10:33 pm 
Offline
User avatar

Joined: Mon Apr 23, 2012 12:28 am
Posts: 760
Location: Huntsville, AL
That's great. Always ready to learn something new myself.

BTW, I don't recognize the synthesizer Cactus II. Who makes it and what FPGA families does it support? Did you get some resource metrics for your core? I would like to see the various resource utilizations against the code you provided. There are so many ways to represent the same circuits in HDL, that I'm always looking for more efficient coding approaches.

_________________
Michael A.


Top
 Profile  
Reply with quote  
 Post subject: Re: MOS 6502 on Verilog
PostPosted: Tue Nov 18, 2014 8:10 pm 
Offline
User avatar

Joined: Fri Jun 22, 2012 7:39 am
Posts: 201
This is Altera Quartus II, sorry for my slang :P

_________________
6502 addict


Top
 Profile  
Reply with quote  
 Post subject: Re: MOS 6502 on Verilog
PostPosted: Thu Nov 20, 2014 9:29 pm 
Offline
User avatar

Joined: Fri Jun 22, 2012 7:39 am
Posts: 201
Completed:
- Decoder
- InstructionRegister
- Predecode
- BranchLogic
- XYSRegs

https://code.google.com/p/breaks/source ... MOS_6502.v

_________________
6502 addict


Top
 Profile  
Reply with quote  
 Post subject: Re: MOS 6502 on Verilog
PostPosted: Sat Nov 22, 2014 10:49 pm 
Offline
User avatar

Joined: Fri Jun 22, 2012 7:39 am
Posts: 201
Flags + Buses:

https://code.google.com/p/breaks/source ... MOS_6502.v

Only RandomLogic, Dispatcher and Program Counter left :)


Attachments:
6502_wip1.png
6502_wip1.png [ 71.99 KiB | Viewed 2568 times ]

_________________
6502 addict
Top
 Profile  
Reply with quote  
 Post subject: Re: MOS 6502 on Verilog
PostPosted: Sun Nov 30, 2014 11:50 am 
Offline
User avatar

Joined: Fri Jun 22, 2012 7:39 am
Posts: 201
Completed.

https://code.google.com/p/breaks/source ... MOS_6502.v

Now its time for error checking :)


Attachments:
6502_RTL_Complete.pdf [82.38 KiB]
Downloaded 389 times

_________________
6502 addict
Top
 Profile  
Reply with quote  
 Post subject: Re: MOS 6502 on Verilog
PostPosted: Sun Nov 30, 2014 6:18 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
I've never seen a 6502 core coded like that style in Verilog. I am no expert in Verilog, but by observation there are alot of 'assign' statements. Wouldn't this imply combinatorial logic? Not saying it's incorrect, just unusual.
BTW, thanks for sharing!

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


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 11 posts ] 

All times are UTC


Who is online

Users browsing this forum: Google [Bot] and 53 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron