Help needed debugging high impedance on RAM read

[David Kaplan]

Hi

I'm having an issue with a cpu that I'm building and no matter what I try, I can't seem to resolve it (so any help would greatly be appreciated):

Basically, when I issue a POP instruction, my processor will read from RAM at the stack pointer address (minus 1). However, the value does not appear on the tristate data bus (it remains in hi-Z); even though it seems to be successfully read from RAM.

You can see the issue in the simulation screenie:

https://www.dropbox.com/s/s9ctbcpqilzzqmc/pop1.bmp

At 110ns mmu1/ram_data is '11111111', however mem_data remains hi-Z (and therefore r0 is hi-Z).

The code is at:

https://github.com/DepletionMode/cupcake/blob/master/cpu/cpu.vhd
https://github.com/DepletionMode/cupcake/blob/master/cpu/mmu.vhd
https://github.com/DepletionMode/cupcake/blob/master/cpu/simpleram.vhd

Apologies for the quality of the code; VHDL isn't my thing (I'm learning I guess.. )

Thanks in advance!

 

[Anssi Saari]

David Kaplan <davkaplan@gmail.com> writes:

Basically, when I issue a POP instruction, my processor will read from RAM at the stack pointer address (minus 1). However, the value does not appear on the tristate data bus (it remains in hi-Z); even though it seems to be successfully read from RAM.

You can see the issue in the simulation screenie:

https://www.dropbox.com/s/s9ctbcpqilzzqmc/pop1.bmp

At 110ns mmu1/ram_data is '11111111', however mem_data remains hi-Z (and therefore r0 is hi-Z).

Well, with a (very) quick look, your mem_data control requires zero in
mem_wr and mem_en but you have zero only in mem_en so mem_data remains
Z. So I guess your tristating isn't really correct then? Do you really
need this and do you really need both enable and write enable for RAM?

> Apologies for the quality of the code; VHDL isn't my thing (I'm learning I guess.. )

It seems a little odd with the white space and I hate it when people
wrap their if conditions in useless brackets. Oh, I also like active low
signals to end in _n but maybe that's just my preference.

 

[Dio Gratia]

On Wednesday, June 18, 2014 6:25:15 AM UTC+12, David Kaplan wrote:

At 110ns mmu1/ram_data is '11111111', however mem_data remains hi-Z (and therefore r0 is hi-Z).

The read process in mmu has ram_data on the right hand side of a conditional signal assignment statement but ram_data isn't in the sensitivity list.

What happens if the ram_data goes valid (non-'Z') in the next delta cycle following some combination of events on n_wr, n_en and addr? You'll have assigned data_out to the ram_data (others => 'Z'). Until another transaction on n_wr, n_en or addr data_out will remain all 'Z's.

Try putting ram_data in the sensitivity list. (This is speculation. It's too much work to write an mmu test bench to test the hypothesis. The operative delay would be the delta delay assigning ram_we - else '0'.)

I also notice that simple_ram_tb_1 transitions the address while the ram enable and write are both true, in general a no-no in an asynchronous RAM (despite the presence of a clock in the test bench). The reason for this is because you can have different propagation times for address signals and could corrupt RAM contents. The issue wouldn't show up in a zero time single dimension array type representation simulation.

It also says at some point you should be concerned with ram_we to ram_addr delay as well as ram_addr to ram_we delay (t=85ns to t=90ns in your BMP). Perhaps you could 'form' the write enable?

Also because the write occurs in 5 ns, you might consider using a synchronous RAM which would cure any potential issues anyway. Trying to find or create two other clock phases to form both edges of ram_we could be tough in an FPGA at that speed and I'd suspect an FPGA vendor would point you at a synchronous RAM. You'd be highly dependent on routing to get the holdovers working. (In other words a 200 MHz internal RAM may not be a simple RAM).

Or is the clock rate a polite fiction at this point? I didn't see any actual specs on your web site.

 

[Dio Gratia]

On Thursday, June 19, 2014 12:21:01 PM UTC+12, Dio Gratia wrote:

Try putting ram_data in the sensitivity list. (This is speculation. It's too much work to write an mmu test bench to test the hypothesis. The operative delay would be the delta delay assigning ram_we - else '0'.)

And I see you already implemented the sensitivity list change:

https://github.com/DepletionMode/cupcake/commit/e836c96016e253fd6d44d73d629fdf46ab794405

 

[rickman]

On 6/17/2014 2:25 PM, David Kaplan wrote:

Hi

I'm having an issue with a cpu that I'm building and no matter what I try, I can't seem to resolve it (so any help would greatly be appreciated):

Basically, when I issue a POP instruction, my processor will read from RAM at the stack pointer address (minus 1). However, the value does not appear on the tristate data bus (it remains in hi-Z); even though it seems to be successfully read from RAM.

You can see the issue in the simulation screenie:

https://www.dropbox.com/s/s9ctbcpqilzzqmc/pop1.bmp

At 110ns mmu1/ram_data is '11111111', however mem_data remains hi-Z (and therefore r0 is hi-Z).

The code is at:

https://github.com/DepletionMode/cupcake/blob/master/cpu/cpu.vhd
https://github.com/DepletionMode/cupcake/blob/master/cpu/mmu.vhd
https://github.com/DepletionMode/cupcake/blob/master/cpu/simpleram.vhd

Apologies for the quality of the code; VHDL isn't my thing (I'm learning I guess.. )

Thanks in advance!

Try looking at your write enable inside the ram module. I think the
sense is reversed somewhere.

Also, in the read process of the MMU is purely combinatorial, but you
have not completely specified all the cases in the IFs and CASE
statements. That generate latches where they are not intended. An easy
way to fix this is to include a single assignment outside of all the
conditional code that sets a default.

data_out <= 0x"ff";

--

Rick