|
Message
From: andrew mulcock<spam@m...>
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@o... [mailto:cores-bounces@o...] On
Behalf Of ronivon.costa@g...
Sent: 05 May 2008 14:28
To: cores@o...
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
