|
Message
From: ronivon.costa at gmail.com<ronivon.costa@g...>
Date: Wed May 7 13:01:03 CEST 2008
Subject: [oc] T80 Core
Hi Andrew,
Things are more like this:
I developed the project first for DE1.
Then, ported to Spartan 3E. I removed the LPM models, and used
Coregen in place.
Almost everything is fine, but, when I add RAM, is messes up both the
RAM and the VRAM. How I can see it does not work? Because I can't read
RAM data anymore, and a working program (which display text on video)
stops from showing the text on video.
I am turning my attention to the clocks now. It may be clock skew issues.
I do not have yet all skills to make a simulation/testbench for this
project, so I am struggling with a trying/error approach to fix this.
I will also take Mike's suggestion, and give a try to the latest T80
release from www.fpgaarcade.com. (Mike, thanks for suggestion, I will
let you know soon how it goes).
Thanks Andrew, and let me know what you think.
----- Original Message -----
From: andrew mulcock<spam@m...>
To:
Date: Tue May 6 09:24:21 CEST 2008
Subject: [oc] T80 Core x
> I'm impressed you managed to move the Xilinx coregen generated
> memory to
> Altera tools, if my memory serves me correct, the Xilinx tools
> point at some
> encrypted file , not the vhdl.
> If it works in Altera and not in Xilinx tools, then you could well
> have a
> porting problem, but in reverse.
> Sounds like you generate the code in Xilinx tools, and it did not
> work ,
> then exported the vhdl to Altera tools, and it did work.
> Ok, one last step, new project in Xilinx, and import the Altera
> code into
> the new project, don't use ANYTHING from the previous Xilinx
> project.
> Does that 'work'. BTW: how are you certain it does not work ? Any
> idea which
> part does not work ?
> I think into the Altera tools you did not move the encrypted Xilinx
> code,
> but the modelsim simulation vhdl of the memory, which the Altera
> tools then
> compiled.
> An initial hunch is that the Xilinx tools are being clever, and
> knowing
> about the core gen stuff, are using one model for simulation one
> for
> synthesis. Use the vhdl from the working Altera design and that
> should force
> the Xilinx tools not to be clever and use the 'dum' vhdl as the
> Altera tools
> did.
> If it works, it does not mean the Xilinx tools are at fault
> initially, I
> just think you might have been trying to out smart them.
> Andrew Mulcock
> -----Original Message-----
> From: cores-bounces at opencores.org [mailto:cores-bounces at
> opencores.org] On
> Behalf Of ronivon.costa at gmail.com
> Sent: 05 May 2008 14:28
> To: cores at opencores.org
> Subject: [oc] T80 Core x
> I would appreciate any help from people who used the T80 core on
> this.
> This is more a multi-discipline problem, because it relates to Z80
> assembly and VHDL:
> I have this logic to read/write into memory.
> DI_CPU is the Z80 input data bus.
> DO_CPU is the Z80 output data bus.
> A is the Z80 address bus.
> The others signals are for video ram (block memory) and other
> devices.
> This process is to store data on memory:
> writevram: process(Clk_Z80)
> begin
> if Clk_Z80'event and Clk_Z80 = '1' then
> if A >= x"2000" and A <= x"27FF" then
> vram_addra_sig <= A - x"2000";
> if Wr_n = '0' and MReq_n = '0' then
> vram_dina_sig <= DO_CPU;
> vram_wea_sig <= '0';
> else
> vram_wea_sig <= '1';
> end if;
> else
> vram_wea_sig <= '1';
> end if;
> end if;
> end process;
> And this continuous assignment is to read memory and input from
> other
> devices and send to the Z80:
> DI_CPU <= D_ROM when (Rd_n = '0' and MReq_n = '0' and A <
> x"2000") else
> ("0000" & SW) when (IORQ_n = '0' and Rd_n = '0'
> and
> A(7 downto 0) =
> x"20") else
> ("0000" & KEY) when (IORQ_n = '0' and Rd_n = '0'
> and
> A(7 downto 0)
> = x"30") else
> ps2_ascii_reg when (IORQ_n = '0' and Rd_n = '0' and
> A(7 downto 0) =
> x"80");
> Now the program in Z80 assembly.
> This next small program will run without problems, and the byte
> will
> be stored in memory. I can have a buch of such commands,in
> sequence,
> and they will run and the data will be stored in memory.
> ld a,41h ; define data to store
> ld (8250),a ; store the data in memory position 8250 decimal
> ld a,42h
> ld (8251),a
> However, if I try to write a block of data, it will fail, and the
> data
> will not be written into memory: ld de,texto ; data to store in
> memory ld bc,2000h ; address of memory to store the data loop1: ld
> a,(de) ; read 1 character or a ; compares with zero jr z,next1 ; if
> zero, then end of text ld (bc),a ; store character in ram inc bc ;
> point to next ram position inc de ; point to next character jr
> loop1 ; go to store next character texto: db "Testing T80 Core
> " db 0 -- So, what do you think it is happening? I have
> considered a T80 bug, but have not come to a definitive test to
> prove that. In the other hand, I really think there is a problem
> with my logic. I am a beginner with VHDL and FPGAs. The memory
> model were generated using coregenerator (xilinx) and implemented
> in a Spartan 3E. The problem does not occur when I use quartus and
> implement the design on a DE1 board. Any thoughts? Ideia? I really
> appreciate. Thanks. _______________________________________________
> http://www.opencores.org/mailman/listinfo/cores No virus found in
> this incoming message. Checked by AVG. Version: 7.5.524 / Virus
> Database: 269.23.8/1414 - Release Date: 04/05/2008 12:31 No virus
> found in this outgoing message. Checked by AVG. Version: 7.5.524 /
> Virus Database: 269.23.8/1414 - Release Date: 04/05/2008 12:31
>
|
 |
Browse
