6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Fri Nov 22, 2024 11:34 pm

All times are UTC




Post new topic Reply to topic  [ 59 posts ]  Go to page Previous  1, 2, 3, 4
Author Message
PostPosted: Sun Nov 17, 2013 7:33 pm 
Offline
User avatar

Joined: Sat Sep 29, 2012 10:15 pm
Posts: 904
I've been using a makefile, much faster. I've also been using FPGA Editor instead of MAP and PAR and bitgen, also faster and possibly better. Just switched back to MAP and PAR and bitgen to see if the problem occurs. Yup, same lockup in BASIC, but perhaps I can look at the timing reports after PAR... Have to take a quick break first.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut


Last edited by enso on Sun Nov 17, 2013 10:34 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Sun Nov 17, 2013 10:33 pm 
Offline
User avatar

Joined: Sat Sep 29, 2012 10:15 pm
Posts: 904
Got the timing report from PAR after placing/routing:
Code:
----------------------------------------------------------------------------------------------------------
  Constraint                                |    Check    | Worst Case |  Best Case | Timing |   Timing   
                                            |             |    Slack   | Achievable | Errors |    Score   
----------------------------------------------------------------------------------------------------------
  TS_clk = PERIOD TIMEGRP "clk" 17 ns HIGH  | MINPERIOD   |    11.013ns|     5.987ns|       0|           0
  50%                                       |             |            |            |        |           
----------------------------------------------------------------------------------------------------------

So it's not a timing-related problem. It seems that there is plenty of slack in the system (the SRAM is the cause of the slow FMax, as evidenced by DILDAR's 100MHz clock).

The input pin flopping directly or indirectly causes the problem (metastability?). I am afraid the mystery remains.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut


Top
 Profile  
Reply with quote  
PostPosted: Sun Nov 17, 2013 11:09 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
enso wrote:
I've been using a makefile, much faster. I've also been using FPGA Editor instead of MAP and PAR and bitgen, also faster and possibly better...

Very interesting. I've never used the Xilinx FPGA editor.
Could you describe the steps you go through to program the FPGA, like what do you use the makefile for?

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


Top
 Profile  
Reply with quote  
PostPosted: Mon Nov 18, 2013 12:13 am 
Offline
User avatar

Joined: Sat Sep 29, 2012 10:15 pm
Posts: 904
I am using Ubuntu. My workflow is entirely a single Makefile (with rare exceptions to see what ISE does...).

Some time ago I discovered that FPGA Editor has routing capability that often beats PAR and is much quicker. It will also generate a bitstream. So I've been using xst - ngbuild - map - fpga_edline - impact workflow. Unfortunately, Xilinx tools are not very clean and there are several script files involved. But it beats ISE as far as I am concerned.

Here is the entire makefile.
make - synthesize, place, route create a bitstream, assemble bootloader and patch it in, create bitstream and flash file.
make burn - burn the FPGA
make flash - program the Platform Flash.
Code:
#
# DO THIS FIRST:
# source /opt/Xilinx/13.2/ISE_DS/settings32.sh
#
DEVICE = xc3s50-5VQ100
FLASHNAME = 6502_45_004

default: bitstreams

#see UG627-xst manual
# Makefile does not track the parts.  Touch top.v!
top.ngc:../hardware/top.v ../hardware/top.ucf ../hardware/top.prj
   xst -intstyle silent -ifn ../hardware/top.xst

top.ngd: top.ngc
   ngdbuild -intstyle silent -dd _ngo -nt timestamp -uc ../hardware/top.ucf  -p $(DEVICE) top.ngc top.ngd

top_map.ncd: top.ngd
   map  -p $(DEVICE) -timing -logic_opt off   \
   -ol high -t 1 -register_duplication off -cm area -detail -ir off -pr b \
   -power off -o top_map.ncd top.ngd top.pcf

top.nocode.bit: top_map.ncd
   fpga_edline top_map.ncd -p ../hardware/fe.scr
   
top.bit: top.nocode.bit ../bootload/boot.as65
   cd ../bootload; ../../bin/as65 -v -l boot.as65; echo $?; ../../bin/bin2mem boot.bin boot.mem
   data2mem -bm ../bootload/bram.bmm -bd ../bootload/boot.mem -bt top.nocode.bit -o b top.bit

bitstreams: top.bit
   cp top.bit ../bitstreams/top.bit
   promgen -w -p mcs -c FF \
   -o ../bitstreams/$(FLASHNAME) -x xcf01s \
   -u 00000000 top.bit
   cp ../bitstreams/$(FLASHNAME).mcs ~/Desktop/SHARED #for enso's setup
   cp top.bit ~/Desktop/SHARED #for enso's setup
   

burn:   top.bit
   impact -batch ../hardware/impact.FPGA.cmd

flash:  ../bitstreams/$(FLASHNAME).mcs
   impact -batch ../hardware/impact.XCF01.cmd
   
   
clean:
   rm -rf *.bgn *.bin *.bit *.xwbt *.bld *.drc *_log *.html *.ncd *.ngc *.ngd *.map *.mrp *.xrpt \
*.ngr *.syr *.twr *.twx *.unroutes webtalk* *_map* *.pad *.lso *.par *.xdl *_summary* *_usage* *.xpi *.stx *.srp \
*.ptwx *.pcf \
_ngo planAhead* iseconfig* _xmsgs xlnx_auto* xst/dump.xst xst/work \
*.prm *.cfi *.hex \
*.log _impact* auto_project* impact.xsl *~


Correction - I misspoke about FPGA Editor mapping the circuit. It does not map, only place and route. Apologies.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut


Last edited by enso on Mon Nov 18, 2013 12:31 am, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Mon Nov 18, 2013 12:31 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
enso wrote:
...Some time ago I discovered that FPGA Editor has routing capability that often beats PAR and is much quicker...

What kind of project were you working on when you discovered this?
I only ask because your way of programming the Xilinx FPGA is so very foreign to me and I'm curious...
I can't offer a solution to your problem unfortunately.

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


Top
 Profile  
Reply with quote  
PostPosted: Mon Nov 18, 2013 12:38 am 
Offline
User avatar

Joined: Sat Sep 29, 2012 10:15 pm
Posts: 904
I was making a little CPU, after being blown away by Ken Chapman's article. HDLs never made much sense to me, and instantiating circuits instantly rang true, as it avoids the entire mapping issue and lets you write code that corresponds to the capabilities of the FPGA. I spent a lot of time looking at how the tools place and route the circuit, and generally exploring the FPGA with the FPGA Editor and XDL. I guess I am more of a hacker then an HDL programmer - I've never simulated or ran a timing analysis on anything in my life.

'The problem' is not really a problem presently, more of a concern that there will be more pain in the future.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut


Top
 Profile  
Reply with quote  
PostPosted: Mon Nov 18, 2013 1:07 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
enso wrote:
...I guess I am more of a hacker then an HDL programmer...

We have something in common there.
enso wrote:
...- I've never simulated or ran a timing analysis on anything in my life...

Running simulations are absolutely critical to what is going on inside the FPGA. It is cycle accurate. For external devices, the faster they are, the closer the simulation will represent what is going on.

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


Top
 Profile  
Reply with quote  
PostPosted: Mon Nov 18, 2013 6:59 am 
Offline
User avatar

Joined: Sat Sep 29, 2012 10:15 pm
Posts: 904
ElEctric_EyE wrote:
Running simulations are absolutely critical to what is going on inside the FPGA. It is cycle accurate. For external devices, the faster they are, the closer the simulation will represent what is going on.


No one could argue with that statement, I suppose.

When I use verilog at a very high level, I have a very loose idea of what the tools will do. I suppose simulations would help. But I try not to do that as I find that it leads to bloated circuits and it's just not satisfying.

When I instantiate circuits, I have a really good idea of how things fit together, including the timing. I can then look at how things fit in the FPGA Editor - since I give the LUTs and flops names, they will be recognizable. I can use placement constraints, or if I want finer control, I use FPGASM. It's more like using integrated circuits to build larger blocks. I suppose I am a dinosaur, but at least I mostly enjoy working with FPGAs.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut


Top
 Profile  
Reply with quote  
PostPosted: Mon Nov 18, 2013 7:09 am 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
It would be interesting to see how much you can speed up the 6502 core when rebuilding it from basic LUTs and placing them manually.


Top
 Profile  
Reply with quote  
PostPosted: Mon Nov 18, 2013 7:23 am 
Offline
User avatar

Joined: Sat Sep 29, 2012 10:15 pm
Posts: 904
Arlet, a while ago I took apart your core and tried to build it up my way. I got sidetracked along the way... I had notes somewhere but lost a hard drive so it's possible they are gone. Your core is pretty good! I am continually amazed at how small it is considering that it's straight up verilog. I suspect it's possible to get it down to a BRAM for the state machine and 150 slices or so for the logic... As for the speed, the core runs at 100MHz on a Spartan3, which is pretty close to the maximum reasonable speed on this platform in my experience.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut


Top
 Profile  
Reply with quote  
PostPosted: Mon Nov 18, 2013 9:34 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
Better to keep the BRAMs for RAM and cache!
Don't forget distributed RAMs, as seen in miniature with Arlet's register file. They are efficient - they might well be a good solution for a 256 byte ROM holding your loader code, so you could even put RAM into page FF for mission mode, and replace with ROM for clean-reset mode.
(The loader could relocate itself to page 0 at boot time... or perhaps could live down there as a shadow ROM/RAM leaving FF untouched.)


Top
 Profile  
Reply with quote  
PostPosted: Mon Nov 18, 2013 3:26 pm 
Offline
User avatar

Joined: Sat Sep 29, 2012 10:15 pm
Posts: 904
We are going pretty off-topic... But I think a single BRAM running the entire 6502 state machine is not a bad investment. I think that's how Michaels core works. There are generally plenty of BRAMs on most chips anyway. CHOCHI has 3 of them free right now.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut


Top
 Profile  
Reply with quote  
PostPosted: Mon Nov 18, 2013 3:34 pm 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
Biggest problem with BRAM is that they're synchronous, so it requires an extra cycle.


Top
 Profile  
Reply with quote  
PostPosted: Mon Nov 18, 2013 7:14 pm 
Offline
User avatar

Joined: Sat Sep 29, 2012 10:15 pm
Posts: 904
Arlet wrote:
Biggest problem with BRAM is that they're synchronous, so it requires an extra cycle.

True, but fortunately the 6502 has no 1-cycle instructions. I believe all 2-cycle instructions can be squeezed into the second cycle, and longer instructions give you even more headroom. In fact, most instructions can be made faster even with the lost decode cycle, if cycle accuracy is not important.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 59 posts ]  Go to page Previous  1, 2, 3, 4

All times are UTC


Who is online

Users browsing this forum: No registered users and 9 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: