Page 4 of 4
Re: CHOCHI E with USB Power
Posted: Sun Nov 17, 2013 7:33 pm
by 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.
Re: CHOCHI E with USB Power
Posted: Sun Nov 17, 2013 10:33 pm
by 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.
Re: CHOCHI E with USB Power
Posted: Sun Nov 17, 2013 11:09 pm
by ElEctric_EyE
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?
Re: CHOCHI E with USB Power
Posted: Mon Nov 18, 2013 12:13 am
by 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.
Re: CHOCHI E with USB Power
Posted: Mon Nov 18, 2013 12:31 am
by ElEctric_EyE
...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.
Re: CHOCHI E with USB Power
Posted: Mon Nov 18, 2013 12:38 am
by 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.
Re: CHOCHI E with USB Power
Posted: Mon Nov 18, 2013 1:07 am
by ElEctric_EyE
...I guess I am more of a hacker then an HDL programmer...
We have something in common there.
...- 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.
Re: CHOCHI E with USB Power
Posted: Mon Nov 18, 2013 6:59 am
by enso
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.
Re: CHOCHI E with USB Power
Posted: Mon Nov 18, 2013 7:09 am
by 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.
Re: CHOCHI E with USB Power
Posted: Mon Nov 18, 2013 7:23 am
by 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.
Re: CHOCHI E with USB Power
Posted: Mon Nov 18, 2013 9:34 am
by 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.)
Re: CHOCHI E with USB Power
Posted: Mon Nov 18, 2013 3:26 pm
by 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.
Re: CHOCHI E with USB Power
Posted: Mon Nov 18, 2013 3:34 pm
by Arlet
Biggest problem with BRAM is that they're synchronous, so it requires an extra cycle.
Re: CHOCHI E with USB Power
Posted: Mon Nov 18, 2013 7:14 pm
by enso
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.