FGPA Anyone?
Re: FGPA Anyone?
Taking another look and noticed that the fx68k CPU is using clk_sys as the clock... isn't that the 84 MHz clock?
Re: FGPA Anyone?
Never mind, I guess the actual CPU clock must be enPhi1 and enPhi2 instead.M68008 wrote:Taking another look and noticed that the fx68k CPU is using clk_sys as the clock... isn't that the 84 MHz clock?
- mk79
- QL Wafer Drive
- Posts: 1349
- Joined: Sun Feb 02, 2014 10:54 am
- Location: Esslingen/Germany
- Contact:
Re: FGPA Anyone?
Yes, basically everything runs on the same base clock and you use enable gates to match the actual required speed.
Re: FGPA Anyone?
I dont't see where 4 cycles are added for word-size ROM access... is that somewhere?
- mk79
- QL Wafer Drive
- Posts: 1349
- Joined: Sun Feb 02, 2014 10:54 am
- Location: Esslingen/Germany
- Contact:
Re: FGPA Anyone?
That is not part of the release version because IIRC the QL stopped booting when it was enabled.
Code: Select all
diff --git a/QL.sv b/QL.sv
index ae3be5f..3f14c1e 100644
--- a/QL.sv
+++ b/QL.sv
@@ -277,7 +277,7 @@ end
//////////////// QL RAM timing ////////////////////
wire ram_delay_dtack;
-wire rom_delay_dtack;
+wire rom_dtack;
ql_timing ql_timing(
.*,
@@ -777,6 +777,7 @@ wire cpu_dtack =
qlsd_sel? qlsd_dtack:
rom_shadow_read || rom_shadow_write? sdram_dtack:
cpu_ram? sdram_dtack && !ram_delay_dtack:
+ cpu_rom? rom_dtack:
1'b1;
// Debugging only
diff --git a/rtl/ql_timing.sv b/rtl/ql_timing.sv
index b435ea1..b0ead66 100644
--- a/rtl/ql_timing.sv
+++ b/rtl/ql_timing.sv
@@ -12,6 +12,9 @@ module ql_timing
input enable,
input ce_bus_p,
+ input cpu_as,
+ input cpu_rw,
+ input cpu_rom,
input cpu_uds,
input cpu_lds,
@@ -19,7 +22,8 @@ module ql_timing
input sdram_oe,
input sdram_dtack,
- output reg ram_delay_dtack
+ output reg ram_delay_dtack,
+ output reg rom_dtack
);
@@ -43,6 +47,9 @@ wire could_start =
// ________________________------------------_____________________________ 16-bit access allowed, chunk 32+
// I WS WS WS WS S3 S2 S1 WN WN WN WN WN WN WN WN WN D1 I
// _______________---------------------------------------------------_____ 16-bit access must wait, chunk < 32
+//
+// I = idle, WS = wait for slot, W4 = STATE 4, Sx = waste slot cycles for 16-bit access, WN = wait for next slot, D1 = allow DTACK
+
typedef enum reg [2:0] {
STATE_IDLE = 3'd0,
STATE_WAIT_START = 3'd1,
@@ -138,4 +145,59 @@ begin
end
end
+
+typedef enum reg [1:0] {
+ ROM_STATE_IDLE = 2'd0,
+ ROM_STATE_WAIT = 2'd1,
+ ROM_STATE_FINISHED = 2'd2
+} rom_delay_state_t;
+
+rom_delay_state_t rom_delay_state;
+reg [1:0] rom_wait_cnt;
+
+
+// Emulate 8-bit bus timing for 16-bit ROM
+always @(posedge clk_sys)
+begin
+ if (reset || !enable)
+ begin
+ rom_dtack <= 1;
+ end else if (ce_bus_p)
+ begin
+ case (rom_delay_state)
+ ROM_STATE_IDLE:
+ begin
+ rom_dtack <= 0;
+ if (cpu_as && cpu_rom)
+ begin
+ if (cpu_uds && cpu_lds)
+ begin
+ // 16-bit read access to QL ROM, delay it
+ rom_wait_cnt <= 2'd3; // The STATE2->STATE4 transition will happen when we go to ROM_WAIT_STATE. Then do additional 4 wait cycles
+ rom_delay_state <= ROM_STATE_WAIT;
+ end else begin
+ // 8-bit access, we're done here
+ rom_dtack <= 1;
+ rom_delay_state <= ROM_STATE_FINISHED;
+ end
+ end
+ end
+
+ ROM_STATE_WAIT:
+ begin
+ rom_wait_cnt <= rom_wait_cnt - 2'd1;
+ if (rom_wait_cnt == 2'd0)
+ begin
+ rom_dtack <= 1;
+ rom_delay_state <= ROM_STATE_FINISHED;
+ end
+ end
+
+ ROM_STATE_FINISHED:
+ if (!cpu_as) rom_delay_state <= ROM_STATE_IDLE;
+ endcase
+ end
+end
+
endmodule
\ No newline at end of file
Re: FGPA Anyone?
I've replaced the timing logic with what I'm implementing for Q-emuLator and it's much more accurate for Mister, too:
However, there must be an issue in IPC/ZX8302 communication, I had to use a hack where I disable ROM wait states when running IPC-related code (range 2F7C - 2FAE in JS ROM).
The SDRAM refresh can also add extra cycles as it's not in sync with the ZX8301 refresh. Haven't looked into how often that happens.
I'll try to clean up the logic and share it.
However, there must be an issue in IPC/ZX8302 communication, I had to use a hack where I disable ROM wait states when running IPC-related code (range 2F7C - 2FAE in JS ROM).
The SDRAM refresh can also add extra cycles as it's not in sync with the ZX8301 refresh. Haven't looked into how often that happens.
I'll try to clean up the logic and share it.
- mk79
- QL Wafer Drive
- Posts: 1349
- Joined: Sun Feb 02, 2014 10:54 am
- Location: Esslingen/Germany
- Contact:
Re: FGPA Anyone?
Funny, I use Test909, tooM68008 wrote:I've replaced the timing logic with what I'm implementing for Q-emuLator and it's much more accurate for Mister, too:
Aaah, yes, that was it, keyboard stops working correctly. Now I remember That was the point when I stopped working on it, too frustrating Of course the core shouldn't be OS specific in the end, but it's an interesting step. Might be difficult to debug, but since I tried the Xilinx ISE debugging environment I view Intel's SignalTap with much more appreciation, it's a 1000 times better.However, there must be an issue in IPC/ZX8302 communication, I had to use a hack where I disable ROM wait states when running IPC-related code (range 2F7C - 2FAE in JS ROM).
SDRAM refresh only takes 0.5 CPU cycles at QL speed, I don't think it really matters. You probably have more speed deviation in real QLs from variance in the crystal (had to improve the QL-VGA core once because one QL was outputting the pixels faster than all the others I have).The SDRAM refresh can also add extra cycles as it's not in sync with the ZX8301 refresh. Haven't looked into how often that happens.
Cool, thanks.I'll try to clean up the logic and share it.
Re: FGPA Anyone?
It's a nice benchmark, at least on the QL. Too short for emulators, though.mk79 wrote:Funny, I use Test909, too
As someone new to FPGA, I found ModelSim very frustrating, it took me a few days to figure out how to make my test bench visible to it and configure a good view. That was months ago... now even though I saved a .do file with the settings, I don't seem to get the same results anymore for that project... I must have forgotten about some obscure steps already.mk79 wrote:Might be difficult to debug, but since I tried the Xilinx ISE debugging environment I view Intel's SignalTap with much more appreciation, it's a 1000 times better.
If SignalTap is different and free, I'll give it a try.
Yes, timings are pretty close, the effect seems to be very small if any.mk79 wrote:SDRAM refresh only takes 0.5 CPU cycles at QL speed, I don't think it really matters.
I've sent you a pull request with the changes. Only tested with a standard QL and QL Speed, I hope it doesn't break the other scenarios too muchmk79 wrote:Cool, thanks.I'll try to clean up the logic and share it.
I have also fixed the IPC communication issue in the ZX8302 logic, mainly by adding a latch to COMDATA.
- mk79
- QL Wafer Drive
- Posts: 1349
- Joined: Sun Feb 02, 2014 10:54 am
- Location: Esslingen/Germany
- Contact:
Re: FGPA Anyone?
Oh wow, I never even tried using ModelSim, though it's probably the professional thing to do.M68008 wrote:As someone new to FPGA, I found ModelSim very frustrating, it took me a few days to figure out how to make my test bench visible to it and configure a good view. That was months ago... now even though I saved a .do file with the settings, I don't seem to get the same results anymore for that project... I must have forgotten about some obscure steps already.
It's integrated in Quartus. It lets you add a logic analyzer into the core. You can define triggers, chose signals, etc. and then just get them live via JTAG while the core is running.If SignalTap is different and free, I'll give it a try.
Well, just looking at it, I think you broke QL-SD on speeds greater than QL by removing most of my cpu_dtack equation But haven't found the time to actually check it out yet.I've sent you a pull request with the changes. Only tested with a standard QL and QL Speed, I hope it doesn't break the other scenarios too much
Great, thanks!I have also fixed the IPC communication issue in the ZX8302 logic, mainly by adding a latch to COMDATA.
Re: FGPA Anyone?
The trick, I've found, to Modelsim comes when you change something in some code way down in the hierarchy => that code and everything upstream needs to be re-compiled.M68008 wrote:As someone new to FPGA, I found ModelSim very frustrating, it took me a few days to figure out how to make my test bench visible to it and configure a good view. That was months ago... now even though I saved a .do file with the settings, I don't seem to get the same results anymore for that project... I must have forgotten about some obscure steps already.
If SignalTap is different and free, I'll give it a try.
Therefore, I use a script (Python/Perl/shell/Make/etc.) to the Modelsim compilation.