CHOCHI E with USB Power

[enso]

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.

[enso]

Got the timing report from PAR after placing/routing:

Code: Select all

----------------------------------------------------------------------------------------------------------
  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.

[ElEctric_EyE]

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?

[enso]

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: Select all

# 
# 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.

[ElEctric_EyE]

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.

[enso]

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.

[ElEctric_EyE]

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.

[enso]

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.

[Arlet]

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.

[enso]

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.

[BigEd]

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.)

[enso]

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.

[Arlet]

Biggest problem with BRAM is that they're synchronous, so it requires an extra cycle.

[enso]

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.