Browse Source

add various development notes

tags/1.1
mntmn 2 months ago
parent
commit
276ac70630
3 changed files with 952 additions and 0 deletions
  1. 0
    0
      notes/vdma_reformatting_plan.txt
  2. 928
    0
      notes/zz9000-r1-bringup-notes.txt
  3. 24
    0
      notes/zz9k-dma-problem.txt

vdma_reformatting_plan.txt → notes/vdma_reformatting_plan.txt View File


+ 928
- 0
notes/zz9000-r1-bringup-notes.txt View File

@@ -0,0 +1,928 @@
what did i do:
- disable SD interface in PS7 block

tried:
- set GPIO 7 high (reset output!)
- seems necessary as well

HDMI interface works when SD block is disabled, GPIO block is active, GPIO 7 is high (out of reset)

new problems in a4000:

- autoconfig fixed by tweaking _sync[x] offset (set to 0)
- seen that CONFOUT was never set

VDMA is starving (?) "Config initialization failed", signal is there but picture is black

what is hogging the memory?
- not the zorro state machine (state is Z3_IDLE)
- not housekeeping in ARM
- maybe videocap has a bug?
- how to debug: make videocap_... registers visible, maybe to ILA

- without videocap, "no signal", VDMA still not running
> Failed to start DMA engine (read channel), status: 0x9
- VDMA looks ok when not re-initialized ever (endless loop after init_video_system)
- fb_fill generated test pattern is displayed!
- disabling video_control_op in RESET and following state...
- next, disabling all init_vdma, video_system_init in the main loop, disabling all mode changes
- freeze when trying a mode test in p96prefs

- memory reads with mon look ok, register reads too
- memory writes with mon are fine (fill)

- issue: i had disabled REGREAD: zorro_ram_write_request reading, but the driver polls this, resulting in endless loop

- on/off toggling of videocap_mode _or_ reading zorro_ram_write_request seems to mess up synth timing

- set default pan point back to 0xe0000, videocap works again! (just hi/lo swapped)

- reenabling init_vdma just for panning again
- can boot to WB in videocap mode and test 720x576 mode successfully!
- uncommenting mode change video_system_inits...
- that works ok!
- switching to 1280x720 works, and it switches back fine to videocap_mode
- full hd 8 bit works!
- workbench switched to 1280x720 bit hangs, old p96 bug afaik
- test 720x576 works, but pointer smears, looks like a byte mask problem
- software failure after a while
- could be z3_ds0... [2]
- could be timing (non) closure

- trying new FW with swapped bytes for videocap
- software change: handle_amiga_reset is back, but without video register poking
- videocap nonfunctional, shows grey screen with black stripes
- p96 mode kinda works but picture shifted by 50% horiz
- trying cold start
- videocap picture is fine!!
- after boot to wb, cap picture is not valigned
- can switch to p96 wb using workaround of having NComm in the back and amiga-m

- menu dropdowns have every 2nd write missing. mask or timing issue?
- fiddling with z3_ds0[x] doesn't help

READ: 00051ca4
'-> ffffffff
READ: 00051cac
'-> 00000000
READ: 00051cb4
'-> 00000000
READ: 00051cbc
'-> 00000000
READ: 00051cc4
'-> 00000000
READ: 00051ccc
'-> 00000000
READ: 00051cd4
'-> 00000000
WRTE: 0004d19c <- cceeee00 [1111]
WRTE: 0004d698 <- 00000000 [1111]
WRTE: 0004d69c <- 4444ee00 [1111]
WRTE: 0004d6a0 <- cceeee00 [1111]
WRTE: 0004d6a4 <- cceeee00 [1111]
WRTE: 0004db9c <- 00000000 [1111]

- reads ending with 8 in address are missing / not seen

- trying to refactor z3_fcs_state a bit
- works, but doesn't fix the READ problem

- hires interlace mode is missing the switching code (currently turned off)


- changing if (znFCS_sync[0] == 'b0) to [1]
- autoconfig stops working?!!?
- uncommenting vsync code in if (zstate==0) ...
- out of range after reset!
- commenting this back fixes the issue!!!

- changing zorro_read code (put on top level and change [1] to [0]):
zorro_read <= zREAD_sync[0];
zorro_write <= ~zREAD_sync[0];
- also doing that for zaddr_in_ram... code
- hangs on boot, autoconfig still ok
- boot without startupseq works, but freezes when execing that
- maybe monitor driver freeze?
- ZSTA stays idle
- bug: double assignment to _read/_write
- after several minutes, system suddenly boots

ZSTA: Z3_IDLE (3200000c) z3: 1 wr: 0 rd: 0 addr: 00001000
ZSTA: Z3_READ_DLY1 (72000012) z3: 1 wr: 0 rd: 1 addr: 00001000
ZSTA: Z3_ENDCYCLE (32000016) z3: 1 wr: 0 rd: 0 addr: 00001000
ZSTA: Z3_IDLE (8e00000c) z3: 1 wr: 1 rd: 0 addr: 0000001c
ZSTA: Z3_READ_DLY1 (4e000012) z3: 1 wr: 0 rd: 1 addr: 00001000
ZSTA: Z3_ENDCYCLE (0e000016) z3: 1 wr: 0 rd: 0 addr: 00001000
ZSTA: Z3_IDLE (b200000c) z3: 1 wr: 1 rd: 0 addr: 00000020
ZSTA: Z3_READ_DLY1 (72000012) z3: 1 wr: 0 rd: 1 addr: 00001000
ZSTA: Z3_ENDCYCLE (32000016) z3: 1 wr: 0 rd: 0 addr: 00001000
ZSTA: Z3_READ_DLY1 (72000012) z3: 1 wr: 0 rd: 1 addr: 00001000
ZSTA: Z3_ENDCYCLE (32000016) z3: 1 wr: 0 rd: 0 addr: 00001000
ZSTA: Z3_IDLE (3200000c) z3: 1 wr: 0 rd: 0 addr: 00001000
ZSTA: Z3_READ_UP (3200000f) z3: 1 wr: 0 rd: 0 addr: 00001000
ZSTA: Z3_READ_DLY1 (72000012) z3: 1 wr: 0 rd: 1 addr: 00001000
ZSTA: Z3_ENDCYCLE (32000016) z3: 1 wr: 0 rd: 0 addr: 00001000
ZSTA: Z3_READ_DLY1 (72000012) z3: 1 wr: 0 rd: 1 addr: 00001000
ZSTA: Z3_ENDCYCLE (32000016) z3: 1 wr: 0 rd: 0 addr: 00001000
ZSTA: Z3_IDLE (3200000c) z3: 1 wr: 0 rd: 0 addr: 00001000
ZSTA: Z3_READ_UP (3200000f) z3: 1 wr: 0 rd: 0 addr: 00001000
ZSTA: Z3_READ_DLY1 (72000012) z3: 1 wr: 0 rd: 1 addr: 00001000
ZSTA: Z3_ENDCYCLE (32000016) z3: 1 wr: 0 rd: 0 addr: 00001000
ZSTA: Z3_IDLE (3200000c) z3: 1 wr: 0 rd: 0 addr: 00001000

- everything fucked after removing double assignment, probably timing fail

- for some reason this was commented out: set_false_path -reset_path -from [get_clocks clk_fpga_0] -to [get_clocks -of_objects [get_pins zz9000_ps_i/clk_wiz_0/inst/CLK_CORE_DRP_I/clk_inst/plle2_adv_inst/CLKOUT0]]
- put this false path back in

- dataout_enable was used unnecessarily in Z3 states (there is already z3_dataout)

- timing is broken. apparently VDMA can break itself.
- enabling slave and master register slices to "auto" on ps7_0_axi_periph
- doesnt do anything good. trying 32 deep fifo for master 0 and slave.


-- addresses are not stable
ZSTA: Z3_ENDCYCLE (02000016) z3: 1 wr: 0 rd: 0 addr: 0203ff94
ZSTA: Z3_IDLE (0200000c) z3: 1 wr: 0 rd: 0 addr: 0203ff94
ZSTA: Z3_READ_DLY1 (42000012) z3: 1 wr: 0 rd: 1 addr: 0002fe98
'-> a58000ff
ZSTA: Z3_ENDCYCLE (02000016) z3: 1 wr: 0 rd: 0 addr: 0002fe98
ZSTA: Z3_IDLE (0200000c) z3: 1 wr: 0 rd: 0 addr: 0002fe98
ZSTA: Z3_READ_DLY1 (42000012) z3: 1 wr: 0 rd: 1 addr: 0000f698
ZSTA: Z3_ENDCYCLE (02000016) z3: 1 wr: 0 rd: 0 addr: 0000f698
ZSTA: Z3_READ_DLY1 (42000012) z3: 1 wr: 0 rd: 1 addr: 0203ff9c
'-> 00002848
ZSTA: Z3_ENDCYCLE (02000016) z3: 1 wr: 0 rd: 0 addr: 0203ff9c
ZSTA: Z3_IDLE (0200000c) z3: 1 wr: 0 rd: 0 addr: 0203ff9c
ZSTA: Z3_READ_DLY1 (42000012) z3: 1 wr: 0 rd: 1 addr: 0203ff90
'-> 00000444
ZSTA: Z3_ENDCYCLE (02000016) z3: 1 wr: 0 rd: 0 addr: 0203ff90
ZSTA: Z3_IDLE (0200000c) z3: 1 wr: 0 rd: 0 addr: 0203ff90
ZSTA: Z3_READ_DLY1 (42000012) z3: 1 wr: 0 rd: 1 addr: 0002fe94
'-> a48000ff
ZSTA: Z3_ENDCYCLE (02000016) z3: 1 wr: 0 rd: 0 addr: 0002fe94
ZSTA: Z3_IDLE (0200000c) z3: 1 wr: 0 rd: 0 addr: 0002fe94
ZSTA: Z3_READ_DLY1 (42000012) z3: 1 wr: 0 rd: 1 addr: 0000f098
ZSTA: Z3_ENDCYCLE (02000016) z3: 1 wr: 0 rd: 0 addr: 0000f098
ZSTA: Z3_READ_DLY1 (42000012) z3: 1 wr: 0 rd: 1 addr: 0002fe98
'-> a58000ff
ZSTA: Z3_ENDCYCLE (02000016) z3: 1 wr: 0 rd: 0 addr: 0002fe98
ZSTA: Z3_IDLE (0200000c) z3: 1 wr: 0 rd: 0 addr: 0002fe98
ZSTA: Z3_READ_DLY1 (42000012) z3: 1 wr: 0 rd: 1 addr: 0000f498
ZSTA: Z3_ENDCYCLE (02000016) z3: 1 wr: 0 rd: 0 addr: 0000f498
ZSTA: Z3_READ_DLY1 (42000012) z3: 1 wr: 0 rd: 1 addr: 0000f69c
ZSTA: Z3_ENDCYCLE (02000016) z3: 1 wr: 0 rd: 0 addr: 0000f69c
ZSTA: Z3_IDLE (0200000c) z3: 1 wr: 0 rd: 0 addr: 0000f69c

---------------------------------

4 paths:

- a is mntzorro so badly designed it is not timeable?
- b is video_tester so badly designed it is not timeable?

- c are missing timing constraints the reason for badness?
- d is the 7mhz clock on a non-clock port the problem?

https://www.xilinx.com/support/answers/63740.html


a: lets disable it!
before: WNS -9.6, TNS -3044
- synth: area optimized
- impl: physopt

-> videocap_save_y2_reg -> videocap_save_addr_reg LoL 9
--> videocap_save_addr <= (videocap_save_y2*videocap_pitch)+videocap_save_x2;
- moved videocap_pitch multiplier to videocap_save_y2 -> TNS -900

- after false pathing clocks, problem on axi_mem_intercon.
- adding registers and fifo 512
- TNS -184!
- some RESET stuff fails timing @ vdma. trying to move interconnect reset to dedicated pin @ psrst
- fails in vmda again, this time some register stuff
- trying to disable "allow unaligned transfers" in vdma
- TNS -22!!!
- Fanout 89 on zorro_state

- lets sort z3 states apart from z2 states
- also put RESET thing in if/else in main fsm
- now -7TNS!!
- create_clock -add -name amiga_e7m -period 143.00 [get_ports ZORRO_E7M];
- makes no_clock stuff go away!

- wire [22:0] z3_addr_out = {data_z3_low16_latched, 7'b111_1111};
- changed ZZZ_ZZZZ to 111_1111 because of tri-cell warning -> fixed
- add register slice and 32 fifo on ps7_0_axi_periph_1
- TNS -7.3!

maybe problematic:\
IDLE:
if (znDS1_sync[2]==0 || znDS0_sync[2]==0 || znUDS_sync[2]==0 || znLDS_sync[2]==0) begin
if ((znUDS_sync[2]==0) || (znLDS_sync[2]==0) || (znDS1_sync[2]==0) || (znDS0_sync[2]==0)) begin
data_z3_hi16 <= default_data;
data_z3_low16 <= default_data;

Z3_READ_DELAY1: begin
if (!zorro_ram_read_request && !zorro_ram_read_flag) begin
data_z3_hi16 <= slv_reg1[31:16];
data_z3_low16 <= slv_reg1[15:0];


Z3_WRITE_UPPER: begin
unnecessary gating

---

- vcap works but is shaky (hsync?) maybe need to spec e7m tighter
- autoconf read returns only FFFFFFFF
- autoconf writes are accepted and lead to IDLE
- zorro read works

ZSTA: Z3_CONFIG (02000018) z3: 1 wr: 0 rd: 0 addr: ff000040
ZSTA: Z3_DTACK (02000017) z3: 1 wr: 0 rd: 0 addr: ff6fff00
ZSTA: Z3_CONFIG (02000018) z3: 1 wr: 0 rd: 0 addr: ffffff00
ZSTA: Z3_AUTOCONF_RD (0200002d) z3: 1 wr: 0 rd: 0 addr: ff000020
ZSTA: Z3_CONFIG (02000018) z3: 1 wr: 0 rd: 0 addr: ffffff2c
ZSTA: Z3_DTACK (02000017) z3: 1 wr: 0 rd: 0 addr: ff03fe48
ZSTA: Z3_CONFIG (02000018) z3: 1 wr: 0 rd: 0 addr: ff03ff5c
ZSTA: Z3_AUTOCONF_RD (0200002d) z3: 1 wr: 0 rd: 0 addr: ffffff70

---> address bytes are noisy

- nothing works anymore.
- autoconf is fixed. depends on how exactly FCS is treated.


ZSTA: Z3_ENDCYCLE (0e000016) z3: 1 wr: 0 rd: 0 addr: 0005adc0
ZSTA: Z3_READ_DLY1 (4e000012) z3: 1 wr: 0 rd: 1 addr: 0005adc0
'-> 44444400
ZSTA: Z3_ENDCYCLE (0e000016) z3: 1 wr: 0 rd: 0 addr: 0005adc8
ZSTA: Z3_READ_DLY1 (4e000012) z3: 1 wr: 0 rd: 1 addr: 0005adc8
'-> 44444400
ZSTA: Z3_ENDCYCLE (0e000016) z3: 1 wr: 0 rd: 0 addr: 0005add0
ZSTA: Z3_READ_DLY1 (4e000012) z3: 1 wr: 0 rd: 1 addr: 0005add0
'-> 44444400
ZSTA: Z3_ENDCYCLE (0e000016) z3: 1 wr: 0 rd: 0 addr: 0005add8
ZSTA: Z3_READ_DLY1 (4e000012) z3: 1 wr: 0 rd: 1 addr: 0005add8
'-> 44444400
ZSTA: Z3_ENDCYCLE (0e000016) z3: 1 wr: 0 rd: 0 addr: 0005add8
ZSTA: Z3_WRITE_UPP (be00000d) z3: 1 wr: 1 rd: 0 addr: 0005adb4
ZSTA: Z3_ENDCYCLE (be000016) z3: 1 wr: 1 rd: 0 addr: 0005adb8
ZSTA: Z3_IDLE (3e00000c) z3: 1 wr: 0 rd: 0 addr: 0005adbc
ZSTA: Z3_ENDCYCLE (be000016) z3: 1 wr: 1 rd: 0 addr: 0005ad9c
ZSTA: Z3_IDLE (be00000c) z3: 1 wr: 1 rd: 0 addr: c0000000
ZSTA: Z3_ENDCYCLE (be000016) z3: 1 wr: 1 rd: 0 addr: 0005adac
ZSTA: Z3_IDLE (be00000c) z3: 1 wr: 1 rd: 0 addr: c0000000
ZSTA: Z3_ENDCYCLE (be000016) z3: 1 wr: 1 rd: 0 addr: 0005adbc
ZSTA: Z3_IDLE (3e00000c) z3: 1 wr: 0 rd: 0 addr: bffffff4
ZSTA: RESET (3e000000) z3: 1 wr: 0 rd: 0 addr: bffffff4

- manual buffer poking works fine, also register writing
- screenmode crashes after initial setup

- changing videocap_save_addr mult back

Read channel config failed, status: 0xF
done.
Read channel dump
MM2S DMA Control Register: 18002
MM2S DMA Status Register: 10001
MM2S HI_FRMBUF Reg: 0
FRMSTORE Reg: 0
BUFTHRES Reg: 0
MM2S Vertical Size Register: 0
MM2S Horizontal Size Register: 0
MM2S Frame Delay and Stride Register: 0
MM2S Start Address 1: 0
halted

- vdma crashes, but amiga doesn't crash!

framebuffer set to 120001
Read channel set buffer address failed, status: 0xF

- weirdly can run again after reboot

REGW: 0000002c <- 00000000 [1100]
CONV: 0000002c <- 00000000
REGW: 0000002c <- 00000000 [0000]
CONV: 0000002c <- 00000000
REGW: 0000001c <- ffffffff [0011]
CONV: 0000001e <- 0000ffff
REGW: 00000020 <- ff00ff00 [0000]
CONV: 00000020 <- ff00ff00
REGW: 00000018 <- 02d002d0 [1100]
CONV: 00000018 <- 000002d0
REGW: 00000030 <- 00020002 [0000]
CONV: 00000030 <- 00020002
REGW: 00000010 <- 02070207 [1100]
CONV: 00000010 <- 00000207
REGW: 00000010 <- 00000000 [0000]
CONV: 00000010 <- 00000000
REGW: 00000014 <- 022e022e [1100]
CONV: 00000014 <- 0000022e
REGW: 00000014 <- 01540154 [0000]
CONV: 00000014 <- 01540154
REGW: 00000020 <- 00010001 [0011]
CONV: 00000022 <- 00000001
FILL: 0 338 340 338 00ffffff

- sometimes regwrites have NO ds bits set!

-----

- ok finally back at original problem
- cursor leaves garbage trail

======

- a new day, a new debugging session.
- autoconfig is OK, we are at TNS -391.
- videocap is OK but no vpos sync (but it's disabled in reset handler), some crawlies on left side
- lets code some testing SW
- not enough RAM for stormc?!
- ASMONE

ZSTA: Z3_ENDCYCLE (86000016) z3: 1 wr: 1 rd: 0 addr: 000100e4
ZSTA: Z3_IDLE (2200000c) z3: 1 wr: 0 rd: 0 addr: 000100e8
ZSTA: Z3_WRITE_UPP (9200000d) z3: 1 wr: 1 rd: 0 addr: 000100e8
ZSTA: Z3_ENDCYCLE (8a000016) z3: 1 wr: 1 rd: 0 addr: 000100e8
ZSTA: Z3_IDLE (0600000c) z3: 1 wr: 0 rd: 0 addr: 000100e8
ZSTA: Z3_WRITE_UPP (a200000d) z3: 1 wr: 1 rd: 0 addr: 000100ec
ZSTA: Z3_ENDCYCLE (92000016) z3: 1 wr: 1 rd: 0 addr: 000100ec
ZSTA: Z3_IDLE (0a00000c) z3: 1 wr: 0 rd: 0 addr: 000100ec
ZSTA: Z3_WRITE_UPP (8600000d) z3: 1 wr: 1 rd: 0 addr: 000100ec <---- write to same addr as before
ZSTA: Z3_ENDCYCLE (a2000016) z3: 1 wr: 1 rd: 0 addr: 000100f0
ZSTA: Z3_IDLE (1200000c) z3: 1 wr: 0 rd: 0 addr: 000100f0
ZSTA: Z3_WRITE_UPP (8a00000d) z3: 1 wr: 1 rd: 0 addr: 000100f0
ZSTA: Z3_ENDCYCLE (86000016) z3: 1 wr: 1 rd: 0 addr: 000100f0
ZSTA: Z3_IDLE (2200000c) z3: 1 wr: 0 rd: 0 addr: 000100f4

but write is ok

read-write pattern is whack:
0 1 2 3 4 5 6 7 8 9 a b c d e f 11
expected:
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

after second run same pattern

- pattern is ok when writing fixed data

- first read gets stuck/smeared to following reads

- write gets the address of the next read?

- removed mntzorro regs + fifo, probably bad idea for timing
- TNS actually gets better /o\ -68
- trying to address a race between reads and writes, putting in some read/write flag checking in IDLE

- bug: read + write req can happen in parallel, overwriting each other's addresses

ZSTA: Z3_IDLE (0200000c) z3: 1 wr: 0 rd: 0 addr: 02022014
ZSTA: Z3_READ_DLY1 (42000012) z3: 1 wr: 0 rd: 1 addr: 00022014
READ: 00022014
'-> 044900ff
ZSTA: Z3_IDLE (0200000c) z3: 1 wr: 0 rd: 0 addr: 00022014

after bugfix gets glitchy address misreads

READ: 00010010
'-> 00000000
ZSTA: Z3_ENDCYCLE (3e000016) z3: 1 wr: 0 rd: 0 addr: 00010010
ZSTA: Z3_READ_DLY1 (7e000012) z3: 1 wr: 0 rd: 1 addr: 02010010
READ: 02010010
'-> 40000100

`-------- 02 instead of 00

WRTE: 00140c04 <- aaaaaa00 [1111]
WRTE: 00140c0c <- aaaaaa00 [1111]
WRTE: 00140c14 <- aaaaaa00 [1111]
WRTE: 00140c1c <- aaaaaa00 [1111]
WRTE: 00140c24 <- aaaaaa00 [1111]
WRTE: 00140c2c <- aaaaaa00 [1111]
WRTE: 00140c34 <- aaaaaa00 [1111]
WRTE: 0014173c <- aaaaaa00 [1111]
WRTE: 00141744 <- aaaaaa00 [1111]
WRTE: 0014174c <- aaaaaa00 [1111]
WRTE: 00141754 <- aaaaaa00 [1111]
WRTE: 0014175c <- aaaaaa00 [1111]
WRTE: 00141764 <- aaaaaa00 [1111]
WRTE: 0014176c <- aaaaaa00 [1111]
WRTE: 00141774 <- aaaaaa00 [1111]

missing every second write again :/

- wrote a test using MOVEM. we see only 5 of 8 READs and 4 of 8 WRITEs. this should be the problem.

- experiment: case (znFCS_sync[2]) <- 2 instead of 1
--> addresses mostly not seen anymore. too late??
- trying [0]
-> brings back autoconfig
-> no junk addrs
- movem test still fails

- dtack_latched -> dtack
- all these things do not fix the movem

--> new strategy: attach ILA to zorro signals and zorro_state
- uds/lds/read sync had undefined top bit, 3:0 instead of 2:0

- its a dtack problem
- amiga needs around 20 fpga (100mhz) cycles to react to DTACK with FCS
- but there is overhang which prematurely breaks the next cycle

=====
another day.

- fixed vsync op bug in arm software (0xf0 vs 0xf0000000)
- enabling VOP writes again in fpga
- theory: wild flicker is from wrong vdiv

- also trying to figure out why moving the cursor crashes after a while
- we could try faking all reads to 0 to see if reads or writes crash


crash in idle state (after setting up screen in p96mode):

ZSTA: Z3_ENDCYCLE (0e000016) z3: 1 wr: 0 rd: 0 addr: 00000000
ZSTA: Z3_IDLE (0e00000c) z3: 1 wr: 0 rd: 0 addr: 00000000
ZSTA: Z3_ENDCYCLE (0e000016) z3: 1 wr: 0 rd: 0 addr: 00000000
ZSTA: Z3_IDLE (0e00000c) z3: 1 wr: 0 rd: 0 addr: 00000000
ZSTA: Z3_READ_DLY1 (4e000012) z3: 1 wr: 0 rd: 1 addr: 001a4ab4
ZSTA: Z3_ENDCYCLE (0e000016) z3: 1 wr: 0 rd: 0 addr: 001a4ab8
ZSTA: Z3_READ_DLY1 (4e000012) z3: 1 wr: 0 rd: 1 addr: 001a4ab8
ZSTA: Z3_ENDCYCLE (0e000016) z3: 1 wr: 0 rd: 0 addr: 001a4ac0
ZSTA: Z3_READ_DLY1 (4e000012) z3: 1 wr: 0 rd: 1 addr: 001a4ac0
ZSTA: Z3_ENDCYCLE (0e000016) z3: 1 wr: 0 rd: 0 addr: 001a4ac8
ZSTA: Z3_READ_DLY1 (4e000012) z3: 1 wr: 0 rd: 1 addr: 001a4ac8
ZSTA: Z3_ENDCYCLE (0e000016) z3: 1 wr: 0 rd: 0 addr: 001a4ad0
ZSTA: Z3_READ_DLY1 (4e000012) z3: 1 wr: 0 rd: 1 addr: 001a4ad0
ZSTA: Z3_ENDCYCLE (0e000016) z3: 1 wr: 0 rd: 0 addr: 001a4ad0
ZSTA: Z3_READ_DLY1 (4e000012) z3: 1 wr: 0 rd: 1 addr: 001a4ad8
ZSTA: Z3_ENDCYCLE (0e000016) z3: 1 wr: 0 rd: 0 addr: 001a4ad8
ZSTA: Z3_READ_DLY1 (4e000012) z3: 1 wr: 0 rd: 1 addr: 001a4ae0
ZSTA: Z3_ENDCYCLE (0e000016) z3: 1 wr: 0 rd: 0 addr: 001a4ae0
ZSTA: Z3_READ_DLY1 (4e000012) z3: 1 wr: 0 rd: 1 addr: 001a4ae8
ZSTA: Z3_ENDCYCLE (0e000016) z3: 1 wr: 0 rd: 0 addr: 001a4ae8
ZSTA: Z3_READ_DLY1 (4e000012) z3: 1 wr: 0 rd: 1 addr: 001a4af0
ZSTA: Z3_ENDCYCLE (0e000016) z3: 1 wr: 0 rd: 0 addr: 001a4af0
ZSTA: Z3_WRITE_FIN (be000015) z3: 1 wr: 1 rd: 0 addr: 001a4acc
ZSTA: Z3_IDLE (3e00000c) z3: 1 wr: 0 rd: 0 addr: 001a4acc
ZSTA: Z3_WRITE_FIN (be000015) z3: 1 wr: 1 rd: 0 addr: 001a4ad0
ZSTA: Z3_IDLE (3e00000c) z3: 1 wr: 0 rd: 0 addr: 001a4ad0
ZSTA: Z3_WRITE_FIN (be000015) z3: 1 wr: 1 rd: 0 addr: 001a4ad4
ZSTA: Z3_IDLE (3e00000c) z3: 1 wr: 0 rd: 0 addr: 001a4ad4
ZSTA: Z3_WRITE_FIN (be000015) z3: 1 wr: 1 rd: 0 addr: 001a4ad8
ZSTA: Z3_IDLE (3e00000c) z3: 1 wr: 0 rd: 0 addr: 001a4ad8
ZSTA: Z3_WRITE_FIN (be000015) z3: 1 wr: 1 rd: 0 addr: 001a4ab4
ZSTA: Z3_IDLE (3e00000c) z3: 1 wr: 0 rd: 0 addr: 001a4ac0
ZSTA: Z3_WRITE_FIN (be000015) z3: 1 wr: 1 rd: 0 addr: 001a4ac4
ZSTA: Z3_IDLE (3e00000c) z3: 1 wr: 0 rd: 0 addr: 001a4ad0
ZSTA: Z3_WRITE_FIN (be000015) z3: 1 wr: 1 rd: 0 addr: 001a4ad4
ZSTA: Z3_IDLE (3e00000c) z3: 1 wr: 0 rd: 0 addr: 001a4ae0
ZSTA: Z3_WRITE_FIN (be000015) z3: 1 wr: 1 rd: 0 addr: 001a4ae4
ZSTA: Z3_IDLE (3e00000c) z3: 1 wr: 0 rd: 0 addr: 001a4af0

- amiga freezes, reboots after a while

- VOPs don't seem to work right, screen goes black quickly

- looks like writes are freezing the cursor? faking reads doesn't hurt it
- trying old DOE gating instead of FCS gating
- no difference

- disabling writes
- dummyfying the writes -> no more crash!
- reenabling reads
- reads don't seem to crash it

- idea: sync last step to e7m

FILL: 0 0 0 0 00000000
FILL: 0 0 0 0 00000000
FILL: 0 0 0 0 00000000
FILL: 0 0 0 0 00000000
FILL: 0 0 0 0 00000000
FILL: 0 0 0 0 00000000
FILL: 0 0 0 0 00000000
FILL: 0 0 0 0 00000000
FILL: 0 0 0 0 00000000

- doesn't seem to crash when debug printfs are off
- nope, can still crash
- without one more DS sampling step in Z3_WRITE_PRE2, all write values are off

- putting if (z3_fcs_state==0) begin back into IDLE
- some states had missing dtack! (regwrite?)

- video_system_init messes up the signal (out of range)
- could it be a fifo/buffer problem?!

- special read/write pattern of the cursor messes things up

- observation: DTACK output after transistor has long slope (300ns+?) for 200ns signal

- new try: disable slaven as soon as we output dtack
- doesn't work but no problem either


- new try: gate DTACK with a timer/counter (10 clocks) in ENDCYCLE.

THIS WORKS! SUCCESS!


===============

another day (2019-07-24)

- todays goal: repair video mode switching
- hdmi_ctrl_init and set_video_mode were logically swapped :O

- one of these is killing the video:
- pixelclock_init
- set_video_mode (this sets only array stuff)
- hdmi_ctrl_init

- it's hdmi_ctrl_init!
- problem solved: hdmi_ctrl_init not needed. chip will reconfig itself.

- onwards to SD boot.
- need to create MBR FAT32 partition with BOOT.bin file
- this is created by SDK -> Xilinx -> Create Boot Image

- first test: FPGA is initialized properly, but not application.


FPGA Done !
p7
In FsblHookAfterBitstreamDload function
Partition Number: 2
Header Dump
Image Word Len: 0x00008004
Data Word Len: 0x00008004
Partition Word Len:0x00008004
Load Addr: 0x00000000
Exec Addr: 0x00000000
Partition Start: 0x000FD490
Partition Attr: 0x00001010
Partition Checksum Offset: 0x001054B0
Section Count: 0x00000001
Checksum: 0xFFDE4442
Application
a0
a1
p-1
mi:0
SDAccess:0x3F5240:0x0:131088
SDAccess:f_read

- comment from main.c in fsbl:

* an application , FSBL will copy the application into DDR and does a
* handoff.The application should not be starting at the OCM address,
* FSBL does not remap the DDR. Application should use DDR starting from 1MB

- so we have to re-place the app to start from DDR and move the videocap stuff to a place where it is not trashing stuff.

heap: 0x2000, stack: 0x2000
ps7_ram_0

- currently videocap is placed at a 14MB offset. that should be fine.
- commented out fb_fill

- right click ZZ9000Test -> Create linker script -> move everything to DDR
- application has no problem starting from DDR, works with FPGA image from amiga

- recreated FSBL (new application)
- complains about ILLEGAL_BOOT_MODE
- turns out SD controller must be activated in PS7
- remember this mucked up our I2C stuff somehow
- works fine now!

===============

- new challenge: reenable Z2 and make it work in A2000

- first trying Z2 in A4000/030
- autoconfig works!
- starting a mode in p96 freezes, arm goes into unknown territory
- maybe code is clobbered by FB? (we have only 64k space and use 16k for stack/heap)
- moved videocap area to 0x1000000 (16 MB?)
- works perfectly! (in A4000/030)

bootgen -image ZZ9000OS.bif -arch zynq -o /home/mntmn/code/ZZ9000_proto/ZZ9000_proto.sdk/ZZ9000Test/bootimage/BOOT.bin -w on

- doesn't work in 2000/040: no autoconfig
- could be that we never raise slaven
- manual read from config space looks good
- Z2_ENDCYCLE can hang
- trying z_ovr <= 0; in z2_endcycle
- this works, or the gate of slaven+dtack with DOE
- a2000 unfreezes upon fpga reload. maybe we need a timeout in endcycle?
- instability with ZZ9000, but... maybe also without?
- more stable with buddha in another zorro slot

=======

- new day, introducing DCM instance from VA2000 to control the vcap offset to combat bad HiRes image in A2000.

- using a clock wizard module. can not go lower than 10mhz input clock :/
- trying -> (videocap_hs[7:1]=='b0000111) instead of 6:1

Thanks for ordering ZZ9000. We're shipping your card(s) soon. To make your first experience with ZZ9000 work well, please answer the following two questions before July 31, 2019.

Please note that you can change to another firmware easily by copying a file to the included MicroSD card.

The videoslot cable connects the ZZ9000CX videoslot card to the main ZZ9000 card to capture the Amiga native video and convert it for the digital video output. In Amiga 2000, the videoslot is far away from the Zorro slots, behind the power supply.

We will offer replacement videoslot cables later in our shop if you need a different length at some point.

https://forms.gle/nDq8i5rWMeCdKpRi6

- MMCM shifting clk1 by 315 degrees and clk2 by 135 degrees solves all color issues :O
- only problem left: unstable "wind" in the picture
- maybe we can do something with the I/O settings?

- wind fixed: (videocap_hs[6:1]=='b000001)
-> forgot at other clock point -> scrambled image, but stable
- fixed for real! videocap_hs[6:1]=='b000011

- GRRR: out of range for p96 screen 320x240 ://
-> 640x480 modes stopped working, others work
- timing is trashed. -11000.
- trying to remove -videocap_prex

- everything is fucked

another day
===========

- changed e7m clock constraint:

create_clock -period 70.000 -name amiga_e7m -add [get_ports ZORRO_E7M]
.CLKIN1_PERIOD(70.000000),

was:
end else if (videocap_hs[6:1]=='b000011) begin
- TNS -409 and very little wind, pixels clean

avenues to try:
a. tighter constraints
b. tweak HS pattern
c. tweak jitter setting (?)
d. tweak -45 degrees

-> fiddling constraints

- period 35 on e7m, 32x multiplier on mmcm
-> -185 TNS
- this makes the image more stable, no wind visible

- change strategy:
- synthesis from areaoptimizedhigh to flow_perfoptimized_high
- impl stays flow_runphysopt
- enable post route physopt


WARNING: [Route 35-41] Unusually high hold violations were detected on a large number of pins. This may result in high router runtime.
Phase 13.4 Update Timing | Checksum: 1aefefa5f

INFO: [Route 35-416] Intermediate Timing Summary | WNS=-0.803 | TNS=-8.633 | WHS=-3.767 | THS=-10596.549|

-> impl was set to some nonsense

- back to -185 TNS. picture almost perfect. screenmodes can be changed again, but some cursor garbage (pixels) in 640x480. full hd works, 320x240 works.

- trying place_design -> ExtraTimingOpt
- TNS -96!
- picture still good

- there is a column of crawlies on the left. lets tweak prex
- changed prex to 2e and removed prex_in

- watching https://www.youtube.com/watch?v=dP3crvjrThc
- what about critical cell replication?
- adding "-critical_cell_opt" to phys_opt_design
-> much worse, -3274

WARNING: [Route 35-447] Congestion is preventing the router from routing all nets. The router will prioritize the successful completion of routing all nets over timing optimizations.
Phase 15.1 Global Iteration 0 | Checksum: e110d31b

- route_design aggressiveexplore option makes it much worse
- try aggressivefanoutopt for phys_opt_design

- trying to remove axi fifo
- trying to remove safety of axi_proto_convert_1

====

- trying to systematically analyze our bad paths.
- video_tester: need_line_fetch_reg2 -> ready_for_vdma caused complicated logic. moved the ready_for_vdma logic into another state. STILL NEED TO TEST
- TNS -547
- next, add registers to axi periph 1
- TNS -547, no change?!
- enable 32 FIFO on axi periph 1
- TNS -186! fifo seems to do something.
- add regs and 32 FIFO on all ports of axi periph
- TNS still -186.
- MM2S linebuffer complaints. lets reintroduce FIFO
- AXI data fifo is back with 32 read/32 write
- worse: -398

- axi_mem_intercon -> change 512 to 32
- add axi4 stream fifo in video subsystem with size 64
- remove axi data fifo
- TNS -610
- disable fifo and regs of axi periph 1
- timing suddenly met!!!

- image is strangely compressed :/
- candidates:
o need_line_fetch_reg2
- trying this first
- TNS -51
- not the problem!
o axi4 stream fifo
- trying this second
- TNS -496
-> important for timing?
- wasn't the problem, display still garbage
- putting fifo back
- 618 :/
- but fifo defaults to 512
- with 32 depth: -103 TNS
- continuing here ...
o "master must be well behaved"
- !! YES, this causes the compressed display if left off !!
- ... image looks clean but byteswap in capture
- screenmodes are OK
- doom is OK
- computer itself is unstable (but was always?)
- screenmode prefs broken?!?!?
- works after cold start
- out of range if reset after rtg screenmode 1280!
O FIXME need to include video formatter code in reset handler?
- whdload works

- lets make a BOOT.bin and try production card
- pretty good, works fine in both A2000s (040, 000) and in A4000/030

=====

- switching ZORRO 3 flag
- timing could be better: -459 TNS
- kind of works, but goes off into glitches and crashes


==============

- another day.
- the mission is to make Z3 fully usable again. starting with -459 TNS.
- removing DCM phase shift for Z3
- much worse, TNS -3175
- try to put it back in but change shift values
- -1198???
- axi_periph_1 has trouble again
- enable 32 deep fifo on it
- 1198, no difference
- -2920 with register slices
- insert another data fifo, -1288
- with all fifos of interconnects disabled, -1629
- replaced interconnects by protocol converters
- aha, -675 TNS
- 608 TNS after data fifo insertion between axi_protoconv_1 and HP0
- congestion strategy takes extremely long (55 minutes) and then finds a -239 TNS solution
- (Congestion_SpreadLogic_medium)
- picture looks solid
- screenmodes are ok again
- bug: if wb is in interlace, rtg mode is cut in half

=============

- FIXME: we should put some buffer regs between videocap_buf bram and m00_axi_wdata and friends

===============

- another day (2019-08-06): almost shipping time!

- finally got warpengine 060 running in A4000 with OS3.1.4 EPROMs.
- we get a RED screen on cold boot but then it starts working
- probably no solution right now... pulldown on INT6 or sth?!?
- some gfx corruption when data cache of 060 is enabled :/
- todo: check mmu lists
- Adoom crashed immediately
- First will install 3.1.4 over 3.9 mess
- lha x crashes immediately
- wget of 3.4 MB os3.1.4 with roadshow was no problem (but downstream limited to around 20kb/s :/)
- overwrite lha with the one from mini:, works fine

- installed os3.1.4 clean from disks, all good now!
- cursor glitch gone
- adoom works
- only about 15 fps tho
- reason: 25mhz 68060, all good

- amigaamp fine
- deluxegalagaaga immediate crash
- whdload broken somehow? superfrog crash
- do we need a new 68060 lib?
- download from aminet is painfully slow

- RED screen is due to contact problems of the cpu connector

- BUG weird flicker/interlace in Full HD 32 bit
- TODO delete altais monitor in installer

- whdload crash is caused by something in Libs:
- working sequence:
assign env: ram:
assign libs: mini:libs
setpatch
stack 100000
whdload superfrog.slave

- BUG ZDoom doesn't load (black screen) bad screenmode?
- BUG 320x256 screenmode is black
- fix: disable in p96prefs
- this also fixes scummVM


- BUG (MED) VDMA can still crash

- FAQ entry: workbench freezes if CLI open during boot


==========================================================

- FINAL TODO for Z3 RELEASE

x check FHD 1920x1080x32 issue
- probably videotester bug?
- videotester is OK
- VDMA can't do it with 100 MHz!
- so we'll ship without the mode
x crawler/flash in left pixel column(s) of vcap
x Installer: delete Altais monitor
o automate Installer archive creation incl. latest device files (on amiga side?)
- just need to include download of the files
- setdate!
x _use_ screenmode doesn't work right (wb freeze)
- not a fault of 68060 library
x ARM apps don't run (core sleeping?!)
- solved by writing asm instrs to 0x140


- FINAL TODO for Z2 RELEASE
- test in A2000/040
- test in A2000/000
- test in A3000/030

- FINAL TODO

o copy BOOT.bin to SD cards and put in Z2/Z3 buckets
o make unique PDFs with a MAC address?
o document known bugs
- rare: swapped pixels on vcap
- ETH rx is slow (20kb/s)
- ARM apps don't yet work on Zorro II
- REMEMBER in demo scripts put a zz9k-loader stop
- 15bit mode not implemented
-

====================

- testing WB hang issue on screenmode change
- it's not the screenmode prefs (same with MUI scrmode)
- same problem with fastiprefs ._.
- is it a bug in workbench?
- lets try a different monitor file! or monitor file options
- must be a bug in workbench, ncomm doesn't have a problem switching modes
- same problem on Mini:
- not cache
- BUG vsync is now not nice in vcap
- not related to 68060. same problem with 68030
- o could it be fastlayers?
- no
- it's not the flags

- debugging this with COP
- workbench task is in a loop
- that ends up in 799a688 which is is_vsynced in our code!
- FIXED by making that routine return 0 or 1

===============================

- gonna solve the ARM app thing now.

+ 24
- 0
notes/zz9k-dma-problem.txt View File

@@ -0,0 +1,24 @@

it's not:

- Z3 vs Z2
- video capture interference
- zorro_ram_write_flag
- timing closure
- READs vs WRITEs
- axi protocol converter (happens with axi interconnect too)
- map_address in driver
- zorro related at all

could be:
-

it happens for:
- DMA writes, on Z2 and Z3
-

- first 2 bytes of a write happen to the place after the last address that was written

- address and data do not fit together
- when the address is given as data, distortions appear


Loading…
Cancel
Save