A. Ruiz, José

Lightweight 8051 compatible CPU

The AC bit after executed SUBB instruction seems to be wrong. For example, executing "SUBB A, R0", if A=0x0a, R0=0x10, AC bit should be clear, but current result is set.

I go through the source code, in line 227 of light52_alu.vhdl, it seems condition "1101" should not be used for AC bit set, is it right?

Thanks & Regards

AC bit result wrong in SUBB

Hi, i think that clr ACC.bit and set ACC.bit instructions doesn't work. I use them in a bench and accu is not modified.

Perhaps because in ALU the last entry of acc_input mux is alu_result instead of result_internal which contains the bitfield_result ?.

Thanks for this great core.

Possible bug on acc.bit

Djnz_dir seems not working.
I my case, i load register B with decimal 10 value and do a loop: 

mov B,#10
loop: djnz b,loop

First djnz put B register to decimal 255 value and jump ?
Same loop with R0 instead of B works fine.

Best Regards.

DJNZ on B register

When generic CODE_ROM_SIZE > 8192, XST synthesizes the XCODE ROM with too many  BRAM blocks.

For example, with CODE_ROM_SIZE=8193 the XCODE uses 4 2KB BRAM blocks; yet, with 8193<=CODE_ROM_SIZE=12288, the XCODE uses 8 BRAM blocks.

This happens in two versions of ISE (9 and 14) and targetting two different generations of Spartan (3 and 6).

There must be something in the code that upsets the XST synthesis tool but not Quartus'. 

Since I haven't tried the project on Xilinx hardware, I don't know if the XCODE is properly initialized despite its wrong size, or if there are other synthesis problems not apparent in the reports.

Browse

Lightweight 8051 compatible CPU