Hi,

I have got some positive results when porting MINSOC to a DE2-70 development board using adbg_if and adv_jtag_bridge.


Now, I can access JSP (polled mode only) and download a ELF program to off-chip SSRAM.

My system has 3 memory modules:

--on-chip SRAM

--off-chip SSRAM (2 Mb)

--off-chip SDRAM (64 Mb)


on-chip SRAM works fine (Initial MINSOC reference design).

Both SSRAM and SDRAM chips, are accessed through two instances of Memory Controller (http://opencores.org/project,mem_ctrl) respectively. A tiny on-chip bootloader writes configuration registers for SSRAM and SDRAM drivers. SSRAM works fine, adv_jtag_bridge writes a program on it without errors.

However, I am having problems with SDRAM chip. I am getting "WB Burst Write Errors" on adv_jtag_bridge output at first attempts of write.


When write accesses come from OpenRISC every thing goes well, this piece of code tests all memory cells without error.

for(k=0;k*(volatile unsigned int *)(SDRAM_BASE 4*k) = k;
ramdata=*(volatile unsigned int *)(SDRAM_BASE 4*k);
if(ramdata!=k){
uart_print_str("Error!.\n");
}


After reading "Memory Controller" documentation, it is explained that busrt transfers do not completely satisfy Wishbone specification. So, I compiled adv_jtag_bridge and adbg_if with "High-Speed" mode disabled and transfer finished correctely, however speed is extremely slow.

Does "Memory Controller" can be used with adv_jtag_bridge in spite of burst transfers differ slightly from Wishbone Specification?

There are reports of use of adv_jtag_bridge with SDRAM memory controllers?

"Versatile Memory Controller" seems to be the right way, however documentation is not clear and I found it hard to use.

Thanks in advance,


Alex Parrado

Hi Alex,

first of all I want to thank you for so many reports; and for going beyond the standard implementation enabling new uses.

So, now to your questions:


I think the reason for the problem does not rely specifically in a Wishbone burst transaction per se, because the SoC does not "support" Wishbone burst transactions anyways. So, it must be some sort of incompatibility due to difference in the timing conditions of the implementations (master/slave) and due to not fully appliance to the specification. Take a look on the following post for more information.



Unfortunately not, I wish there were and I wish I had the time and the hardware :-P.



I'm not completely sure about that. Last time I was curious about these things I have written this post: http://opencores.org/forum,OpenRISC,0,3442

That might have some information regarding your questions. But I don't think that the "Versatile Memory Controller" is the solution for now (Development status: Planning). By the time I wrote that post it was already at that point. There haven't been many developments in memory controllers from this website for quite some time.

SOME INFO/IDEAS

I am aware already quite some time of the need for external memory support (see minsoc project page TODO). Unfortunately I haven't had the time lately to go for it. Besides, I also lack the required hardware. My board, Spartan 3A DSP Kit, includes a DDR2 RAM, for which the only available memory controllers are MIG (Xilinx memory IP) based.

For those who have a DDR2 memory, I already pointed someone to XSOC, which has exactly that memory implementation. Orpsocv2 probably has the same? (my infos on orpsocv2 are somewhat outdated).

About the burst issue, that is odd. To be fair, the current minsoc interconnect does not support Wishbone bursts, neither does the on-chip RAM. It would be fairly easy to adapt the interconnect to support Wishbone bursts. All that is required are the insertion of wb_cti and wb_bte outputs for initiators and same signal inputs for targets. However, the bursts will only work if the Wishbone controller on the slave devices implements the burst logic.

That being said, the interoperational problem you're experiencing could actually be something else. Best would be to analyze the RTL code from the Wishbone interface of the memory controller and check how it expects the bitwindows, sort of a clock based timing analysis. Then check how the adbg_if.v issues those commands. Try to figure out what are the differences between the "high-speed" and regular mode, so you can possibly see why one works and the other does not.

Maybe some signs are missing on your code snippet, because it seems only to write and read always from the same memory address (last for part is k only). That's why I couldn't tell if the following has already been tested. One supposition is that unaligned writes/reads do not work well with the controller you picked. That would be really odd, but regularly you'd only perform unaligned accesses out of the Wishbone data interface and only if that's what you're aiming for. On the other hand, the adv_jtag_bridge writes byte-wise to the memory performing innumerous unaligned accesses.

Best regards and I hope that helps. Sorry for the bad news.
Raul

PS: I took the liberty of thanking you for your report on minsoc evaluation on your board by openly publishing the information on the Status part of minsoc project page. Please, let me know if that is not ok for you.

You're welcome!, supporting open hardware rules !!! :)




Good info, Thanks.







So sad.




Thanks a lot!!!.



It's perfect. thanks.

I have succeeded in using adv_jtag_bridge with the mem_ctrl SDRAM controller - that's actually how I test the speed of my cable drivers. Since my board has no external SRAM, the SDRAM is the only place with enough space to hold the ~1MB of data I use for a benchmark transfer.

I'm assuming you're using a USB-Blaster. What clock speeds are you using for your WishBone and mem_ctrl? I use a USB-Blaster clone, a WishBone clock of 20MHz and an SDRAM clock of 10 MHz. At these speeds, the SDRAM seems to be able to keep up with the JTAG transfer (which GDB reports as 88k/sec).

The mem_ctrl lack of burst support shouldn't matter. Adv_dbg_if never uses WishBone bus bursts.

When ADBG_HISPEED is turned OFF, then the debug system basically polls until the WishBone has finished the previous transaction before starting a new transfer. This guarantees the JTAG transfer will not overrun the WishBone but, as you've discovered, it's very slow. I really do wonder if your SOC clock speeds just aren't keeping up with the JTAG.

Also, you said you got the JSP working. Did you have to change anything to make it work?

Glad to hear a report from someone experimenting with this stuff...
Nathan

Hi Nathan,

I believe he posted the necessary changes for minsoc to make it work, here: http://opencores.org/forum,OpenRISC,0,4003

Basically he just included the connection, enabled the JSP on adv_debug_sys and updated the firmware accordingly (changing base address and IRQ line).

Best regards,
Raul

Hi Nathan, interrupt is not fully working yet, polled mode instead.

Hi Guys,

I came back trying to solve this issue.

I used a 20 MHz wishbone clock and a 10 MHz sdram clock as nathan suggested, however problem persists. So, trying to avoid any synchronization risk between adbg module and memory controller, I have used jtag tck clock from altera_virtual_jtag as wishbone clock (around 10 MHz acording to Altera user guide), and a prescaled version for sdram clock, unfortunatelly error persists.

In both cases SDRAM can be read and writen from OR1200 master interface (a custom program writes and verifies all memory cells), using adbg module, burst errors appear at adv_jtag_bridge terminal, and connection gets closed.

Thanks in advance guys.

Best regards.

Hello again!

First, the system will never work if you use the JTAG clock (TCK) as the system clock. The JTAG clock only runs when data is being transferred via JTAG - it is not a free-running clock.

I still think the JTAG clock is just too fast for the system. If the USB-Blaster is really running at 10 MHz, and your SDRAM is running at 10 MHz, that is probably the problem. The SoC only has 8 or 9 JTAG clock ticks to get the data from the SDRAM, and 3-4 of those are used in clock domain synchronization. I don't know if the SDRAM controller you're using can do memory reads that fast, but it seems possible that it does not.

I suggest running your SoC at the highest clock rate you safely can. I don't know of any way to slow down the USB-Blaster clock rate.