[System09] Bug report for the System09_Digilent_3S200.vhd

[John Kent]

Prof. Dr.-Ing. Marco Winzker has reported a couple of bugs in the 
Digilent 3S200 version of System09.

"I use the Digilent XS200 board. In System09_Digilent_3S200.vhd you use 
two different clocks with the same speed. I encountered problems with 
clock domain transfers, so I just merged the clocks. Also this 25 MHz 
clock must be in the user constraints. The constraint will be violated 
slightly, but without it the design failed to work."

Modifications:

System09_Digilent_3S200.vhd – line 616

REMOVE:

vga_clk_buffer : BUFG port map(

i => clk_count,

o => vga_clk

);

INSERT:

vga_clk <= cpu_clk;


System09_Digilent_3S200.ucf – after line 136

INSERT:

NET "cpu_clk" TNM_NET = "cpu_clk";

TIMESPEC "TS_cpu_clk" = PERIOD "cpu_clk" 40 ns LOW 50 %;


He suggests that other versions of the design may also need modification.
I have not had any problem with ISE 7.1 or 8.1 but perhaps there is a 
problem with more recent versions of ISE.
The reason I split the clocks was that I was concerned about clock loading.

I've been updating David Burnette's makefiles and S1 to VHDL ROM utility 
to support variable length S1 records and to support 4KBit block RAMs 
found on the Spartan 2, although I got a bit stuck on how to specify if 
the ROMs are B4 or B16 ROMs in the makefile.

I was using a Spartan 2 board with a LANTRONIX AR Ethernet to serial 
port board, but I could not get the X Modem upload program to work 
properly. It worked fine over a direct serial COMs connection, using 
X-Modem protocol on Hyperterm, but It would not work using a TCP-IP 
socket via the LANTRONIX card. I thought the problem might have been in 
the hardware flow control, so I have been adding that to all the monitor 
ROMs.

The upshot is that the design is in limbo, until I can find time to sort 
out all the problems, and get the package up and running again.

I also got an email from Brian Dominy who wrote and maintains gcc6809. 
He was telling me his emulator was capable of running Dr Ed Cheung's 
pinball game, which had problems with the FIRQ when he used my CPU09. Ed 
solved the problem by setting the Entire Flag in the FIRQ microcode, 
although it would be good to know why that fixed the problem. There is 
not much I can do to resolve that problem until I can get a logic trace 
at the point the program crashes. I have been unable to reproduce the 
problem with my hardware so it might be a cycle accuracy problem.

System09 does not pay the bills and my Ph.D is running off track due to 
extra curricular interest.

John.

-- 
http://www.johnkent.com.au
http://members.optushome.com.au/jekent