leonard.bise | 10 Apr 16:40 2014
Picon

Simple hello world not printfing anything in tsim-leon



Hello,
I'm running on Ubuntu 12.04 LTS.
I have a very simple hello world program:
#include <stdio.h>

int main(void)
{
  printf("Hello world!\n");
  return 0;
}

I compile this code with sparc-elf-gcc -g hello.c -o hello.exe
sparc-elf-gcc is latest from the website :
sparc-elf-gcc (BCC 4.4.2 release 1.0.44) 4.4.2
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

An d I'm trying to run it in tsim like so:
tsim-leon
then I get no print when executing it:
bisel <at> serv-its:~/network/home/mkprom_leo$ ~/tsim-leon-2.0.26/tsim/linux/tsim-leon

 TSIM/LEON SPARC simulator, version 2.0.26 (professional version)

 Copyright (C) 2013, Aeroflex Gaisler - all rights reserved.
 For latest updates, go to http://www.gaisler.com/
 Comments or bug-reports to support-FkzTOoA/JUlBDgjK7y7TUQ@public.gmane.org

serial port A on stdin/stdout
allocated 4096 K RAM memory, in 1 bank(s)
allocated 32 M SDRAM memory, in 1 bank
allocated 2048 K ROM memory
icache: 1 * 4 kbytes, 16 bytes/line (4 kbytes total)
dcach e: 1 * 4 kbytes, 16 bytes/line (4 kbytes total)
tsim> load hello.exe
section: .text, addr: 0x40000000, size 24608 bytes
section: .data, addr: 0x40006020, size 2912 bytes
read 285 symbols
tsim> ru
starting at 0x40000000


Program exited normally.
tsim>

What is going on? Where is my printf going? :/




__._,_.___


__,_._,___
alhawaj | 9 Apr 08:04 2014
Picon

Micron DDR3 Model



Hello Everyone,

I was trying to simulate ML605 using vsim on the latest package grlib-gpl-1.3.4-b4140. I ended up with errors that the ports on DDR3 model in verilog mismatch the ports defined in the testbench in VHDL. After a bit of investigation, I figured out that the problem comes from here:

    inout   dm_tdqs;                        < THIS LINE
    input   [BA_BITS-1:0]   ba;
    input   [ADDR_BITS-1:0] addr;
    inout   [DQ_BITS-1:0]   dq;
    inout   dqs;                            < THIS LINE
    inout   dqs_n;                          < THIS LINE

These ports should be defined as an array. Therefore, I changed their definition to:

    inout   [DM_BITS-1:0]   dm_tdqs;
    input   [BA_BITS-1:0]   ba;
    input   [ADDR_BITS-1:0] addr;
    inout   [DQ_BITS-1:0]   dq;
    inout   [DQS_BITS-1:0]  dqs;
    inout   [DQS_BITS-1:0]  dqs_n;

I didn't have the chance to simulate the design as I am still fixing some modifications I made unrelated to this, but my modification made the vsim-compile of the design to go smoothly. However, did I modify the files correctly and is my assumption correct in this situation?

-Khalid



__._,_.___


__,_._,___
Jack Morrison | 9 Apr 07:43 2014

Getting started/RAM simulation error

Hello. I'm trying to get up to speed on building a LEON3 system. I've 
run into a number of minor issues that I've been able to work around, 
but I'm getting stuck while running a behavioral simulation.

My setup is:
- Windows 7 64-bit, Cygwin (I suspect things would have gone easier 
under Linux)
- grlib-gpl-1.3.4-b4140
- Xilinx ISE 14.7 WebPack (note that Vivado tools don't support Spartan6)
- BCC 1.0.44

I'm starting from the leon3-gr-xc6s sample design. The only change I 
made was to disable gigabit ethernet since that's not supported in the 
GPL version. I ran "make mig39" and "make install-secureip" okay.

I got the dreaded Cygwin fork failures running "make planAhead". To work 
around this, I broke it into steps:
	make -n planAhead/leon3mp_planAhead.tcl >! foo
	bash foo
	make planAhead

That runs and eventually builds a bit file (the actual board hasn't 
arrived yet so I don't know if the bit file will work). There are over 
3000 warnings though, and I worry that some of them shouldn't be ignored.

I was also able to "make soft" and build prom.srec and ram.srec.

The real fun begins with simulation. I loaded the leon3mp.xise into ISE 
Navigator, selected Simulation view and testbench.vhd as top-level file, 
and ISim simulator process. Unlike the planAhead tool, this seems to 
have a lot of trouble loading the VHDL files, giving bogus complaints 
about circular references and components missing from the libraries. I 
got it to work eventually by renaming work.config to work.bconfig (so it 
wouldn't confuse it with grlib.config), and toggling from manual to auto 
compile order and back, and then rearranging the order on some files.

The simulator starts up, and I get messages showing components being 
initialized (copied below). And I can see the main clock running, and 
reset go inactive. But then I run into trouble:

at 3176001 ps(2), Instance /testbench/ddr2mem/\ddr2mem0(0)\/u1/ : 
Warning: WARNING : (STATE_MACHINE) : Illegal Command Issued. Command 
Ignored.
[this repeats every 4 ns]

I tried to trace this down, it looks like the memory instance is 
decoding an "error" command because RAS and CAS (among other signals) 
are Undefined (they start out as "Z" but change to "U" after reset 
finishes and the ddrclk starts toggling).

Probably some of these earlier warnings are relevant, but I don't know 
how to fix them:

[from fuse.log]
Starting static elaboration
WARNING:HDLCompiler:89 - 
"...mig39/mig_39/user_design/rtl/mcb_raw_wrapper.vhd" Line 4093: <mcb> 
remains a black-box since it has no binding entity.
WARNING:HDLCompiler:220 - 
"...grlib-gpl-1.3.4-b4140/lib/gaisler/sim/sram.vhd" Line 93: Assignment 
ignored
Completed static elaboration
WARNING:Simulator:648 - 
"...mig39/mig_39/user_design/rtl/mcb_raw_wrapper.vhd" Line 4093. 
Instance mcb is unbound

[from isim.log]
Simulator is doing circuit initialization process.
at 0 ps, Instance

/testbench/cpu/mig_gen/ddrc/MCB_inst/memc3_wrapper_inst/memc3_mcb_raw_wrapper_inst/gen_term_calib/mcb_soft_calibration_top_inst/mcb_soft_calibration_inst/ 
: Warning: There is an 'U'|'X'|'W'|'Z'|'-' in an arithmetic operand, the 
result will be 'X'(es).
at 0 ps: Note: The 200 us wait period required before CKE goes active 
has been skipped in Simulation 
(/testbench/cpu/mig_gen/ddrc/MCB_inst/memc3_wrapper_inst/memc3_mcb_raw_wrapper_inst/gen_term_calib/mcb_soft_calibration_top_inst/mcb_soft_calibration_inst/).
Finished circuit initialization process.
LEON3 GR-XC6S-LX75 Demonstration design
GRLIB Version 1.3.4, build 4140
Target technology: spartan6  , memory library: spartan6
ahbctrl: AHB arbiter/multiplexer rev 1
ahbctrl: Common I/O area disabled
ahbctrl: AHB masters: 4, AHB slaves: 16
ahbctrl: Configuration area at 0xfffff000, 4 kbyte
ahbctrl: mst0: Aeroflex Gaisler        LEON3 SPARC V8 Processor
ahbctrl: mst1: Aeroflex Gaisler        AHB Debug UART
ahbctrl: mst2: Aeroflex Gaisler        JTAG Debug Link
ahbctrl: mst3: Aeroflex Gaisler        GR Ethernet MAC
ahbctrl: slv0: European Space Agency   LEON2 Memory Controller
ahbctrl:       memory at 0x00000000, size 512 Mbyte, cacheable, prefetch
ahbctrl: slv1: Aeroflex Gaisler        AHB/APB Bridge
ahbctrl:       memory at 0x80000000, size 1 Mbyte
ahbctrl: slv2: Aeroflex Gaisler        LEON3 Debug Support Unit
ahbctrl:       memory at 0x90000000, size 256 Mbyte
ahbctrl: slv4: Aeroflex Gaisler        Xilinx MIG DDR2 Controller
ahbctrl:       memory at 0x40000000, size 128 Mbyte, cacheable, prefetch
ahbctrl: slv6: Aeroflex Gaisler        Test report module
ahbctrl:       memory at 0x20000000, size 1 Mbyte
ahbctrl: slv13: Aeroflex Gaisler        AHB/APB Bridge
ahbctrl:       memory at 0x80100000, size 1 Mbyte
apbctrl: APB Bridge at 0x80000000 r
apbctrl: slv0: European Space Agency   LEON2 Memory Controller
apbctrl:       I/O ports at 0x80000000, size 256 byte
apbctrl: slv1: Aeroflex Gaisler        Generic UART
apbctrl:       I/O ports at 0x80000100, size 256 byte
apbctrl: slv2: Aeroflex Gaisler        Multi-processor Interrupt Ctrl.
apbctrl:       I/O ports at 0x80000200, size 256 byte
apbctrl: slv3: Aeroflex Gaisler        Modular Timer Unit
apbctrl:       I/O ports at 0x80000300, size 256 byte
apbctrl: slv4: Aeroflex Gaisler        PS2 interface
apbctrl:       I/O ports at 0x80000400, size 256 byte
apbctrl: slv5: Aeroflex Gaisler        PS2 interface
apbctrl:       I/O ports at 0x80000500, size 256 byte
apbctrl: slv6: Aeroflex Gaisler        SVGA frame buffer
apbctrl:       I/O ports at 0x80000600, size 256 byte
apbctrl: slv7: Aeroflex Gaisler        AHB Debug UART
apbctrl:       I/O ports at 0x80000700, size 256 byte
apbctrl: slv9: Aeroflex Gaisler        AMBA Wrapper for OC I2C-master
apbctrl:       I/O ports at 0x80000900, size 256 byte
apbctrl: slv10: Aeroflex Gaisler        General Purpose I/O port
apbctrl:       I/O ports at 0x80000a00, size 256 byte
apbctrl: slv11: Aeroflex Gaisler        General Purpose I/O port
apbctrl:       I/O ports at 0x80000b00, size 256 byte
apbctrl: slv12: Aeroflex Gaisler        General Purpose I/O port
apbctrl:       I/O ports at 0x80000c00, size 256 byte
apbctrl: slv13: Aeroflex Gaisler        AHB Status Register
apbctrl:       I/O ports at 0x80000d00, size 256 byte
apbctrl: slv14: Aeroflex Gaisler        GR Ethernet MAC
apbctrl:       I/O ports at 0x80000e00, size 256 byte
apbctrl: slv15: Aeroflex Gaisler        Gaisler RGMII Interface
apbctrl:       I/O ports at 0x80001000, size 4 kbyte
apbctrl: APB Bridge at 0x80100000 r
apbctrl: slv0: Aeroflex Gaisler        Xilinx MIG DDR2 Controller
apbctrl:       I/O ports at 0x80100000, size 256 byte
leon3_0: LEON3 SPARC V8 processor rev 3
leon3_0: icache 2*8 kbyte, dcache 2*4 kbyte
dsu3_2: LEON3 Debug support unit + AHB Trace Buffer, 4 kbytes
ahbuart7: AHB Debug UART rev 0
ahbjtag AHB Debug JTAG rev 2
testmod6: Test report module
apbuart1: Generic UART rev 1, fifo 4, irq 2, scaler bits 12
irqmp: Multi-processor Interrupt Controller rev 3, #cpu 1, eirq 0
gptimer3: GR Timer Unit rev 0, 8-bit scaler, 2 32-bit timers, irq 8
apbps2_4: APB PS2 interface rev 2, irq 4
apbps2_5: APB PS2 interface rev 2, irq 5
svgactrl6: SVGA controller rev 0, FIFO length: 384, FIFO part length: 
128, FIFO address bits: 9, AHB access size: 32 bits
i2cmst9: AMBA Wrapper for OC I2C-master rev 3, irq 3
grgpio10: 16-bit GPIO Unit rev 2
grgpio11: 32-bit GPIO Unit rev 2
grgpio12: 28-bit GPIO Unit rev 2
ahbstat13: AHB status unit rev 0, irq 1
greth3: 10/100 Mbit Ethernet MAC rev 03, EDCL 1, buffer 16 kbyte 256 
txfifo, irq 6
at 4 ns(3), Instance /testbench/cpu/rgmii0/ : Warning: NUMERIC_STD."=": 
metavalue detected, returning FALSE
[last one repeats 5 more times]

So... is it apparent what I'm doing wrong, or at least what I need to do 
next to make it work? I'm expecting it to run the "GRLIB system test" 
code as described in the library user's manual.

Many thanks for any suggestions.

------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/LEON_SPARC/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/LEON_SPARC/join
    (Yahoo! ID required)

<*> To change settings via email:
    LEON_SPARC-digest@... 
    LEON_SPARC-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    LEON_SPARC-unsubscribe@...

<*> Your use of Yahoo Groups is subject to:
    https://info.yahoo.com/legal/us/yahoo/utos/terms/

paul8mnt | 9 Apr 02:32 2014
Picon

Amba AHB grant unexpected behavior



Hi everybody,

I have designed a peripheral for Leon3 SoC which has an APB slave interface to read/write registers and an AHB master interface that reads data from DRAM, does some computation, then stores the data back to memory. The processor is not involved in the memory transaction, except for the allocation of the region in memory.

The sequence of operations is the following:

1- User app mmaps a buffer in memory and initializes it
2- User app invokes a driver that flushes the cache and pins the pages where the buffer is located
3- The driver writes the registers of the peripheral to start it
4- The driver puts the thread to sleep waiting for the interrupt
5- When the peripheral i s done, the IRQ wakes the thread
6- The driver checks the status and returns to user space
7- Finally the user app checks the result.

grlib version: grlib-gpl-1.3.4-b4140
Linux verion: 3.8.0
Board: vc707 and xupv5

Most of the times everything works fine, however, sometimes I noticed using chipscope that the AHB grant does not return to the processor when my peripheral releases the request.
Is this an expected behavior? RTL simulation and bare metal (with chipscope) show that the grant should return to the processor as soon as the peripheral releases the request (as long as nobody else has priority).
Do you have any suggestions on where I should look inside the code of the bus controller (which so far I have not touched)?


I also have a second unrelated issue: the Ethernet is not working on vc707. I saw a patch on the group and I tried it, but it didn't work. Do I need to set some specific parameters with xconfig to make it work?

Thank you in advance.
Paolo




__._,_.___


__,_._,___
bhavishya.goel | 7 Apr 15:07 2014
Picon

Frequency for Nexys 4 board



Hi,

Has the Nexys 4 board tested with main clock (clkm) frequency other than 50 MHz? I tried changing the clkm frequency from 50 MHz to 25 MHz and ran into timing errors. Apparently, this is because of data path from 25 MHz main clock domain to 50 MHz RMII clock (eth_clk90) domain. Here is an example of the output from timing report:

Timing constraint: TS_eth_clk90_nobuf = PERIOD TIMEGRP "eth_clk90_nobuf"
TS_sys_clk_pin * 0.5         PHASE 5 ns HIGH 50%;
For more information, see Period Analysis in the Timing Closure User Guide (UG612).

 11316 paths analyzed, 1590 endpoints analyzed, 1 failing endpoint
 1 timing error detected. (1 setup error, 0 ho ld errors, 0 component switching limit errors)
 Minimum period is  21.044ns.
--------------------------------------------------------------------------------
Slack:                  -0.261ns (requirement - (data path - clock path skew + uncertainty))
  Source:               eth0.e1/m100.u0/ethc0/r_txlength_2 (FF)
  Destination:          eth0.e1/m100.u0/ethc0/tx_rmii1.tx0/r_tx_en (FF)
  Requirement:          5.000ns
  Data Path Delay:      4.547ns (Levels of Logic = 3)
  Clock Path Skew:      -0.394ns (3.883 - 4.277) div>
  Source Clock:         clkm rising at 0.000ns
  Destination Clock:    eth_clk90 rising at 5.000ns
  Clock Uncertainty:    0.320ns

  Clock Uncertainty:          0.320ns  ((TSJ^2 + DJ^2)^1/2) / 2 + PE
    Total System Jitter (TSJ):  0.070ns
    Discrete Jitter (DJ):       0.330ns
    Phase Error (PE):           0.150ns

  Maximum Data Path at Slow Process Corner: eth0.e1/m100.u0/ethc0/r_txlength_2 to eth0.e1/m100.u0/ethc0/tx_rmii1.tx0/r_tx_en
    Location             Delay type         Delay(ns)  Physical Resource
                                                       Logical Resource(s)
    -------------------------------------------------  -------------------
    SLICE_X23Y159.BQ     Tcko                  0.379   eth0.e1/m100.u0/ethc0/r_txlength(2)
                                                       eth0.e1/m100.u0/ethc0/r _txlength_2
    SLICE_X24Y158.D3     net (fanout=13)       0.688   eth0.e1/m100.u0/ethc0/r_txlength(2)
    SLICE_X24Y158.CMUX   Topdc                 0.449   eth0.e1/m100.u0/ethc0/tx_rmii1.tx0/r_tx_en_PWR_131_o_MUX_7089_o11
                                                       eth0.e1/m100.u0/ethc0/tx_rmii1.tx0/r_tx_en_PWR_131_o_MUX_7089_o111_F
                                                &n bsp;      eth0.e1/m100.u0/ethc0/tx_rmii1.tx0/r_tx_en_PWR_131_o_MUX_7089_o111
    SLICE_X25Y162.D6     net (fanout=5)        0.523   eth0.e1/m100.u0/ethc0/tx_rmii1.tx0/r_tx_en_PWR_131_o_MUX_7089_o11
    SLICE_X25Y162.D      Tilo                  0.105   eth0.e1/m100.u0/ethc0/tx_rmii1.tx0/r_tx_en_PWR_131_o_MUX_7089_o
                                                       eth0.e1/m100.u0/ethc0/tx_rmii1.tx0/r_tx_en_PWR_131_o_MUX_7089_o116
    SLICE_X0Y175.A6      net (fanout=5)        1.161   eth0.e1/m100.u0/ethc0/tx_rmii1.tx0/r_tx_en_PWR_131_o_MUX_7089_o
    SLICE_X0Y175.A       Tilo                  0.105   eth0.e1/m100.u0/ethc0/tx_rmii1.tx0/r_main_state[3]_X_108_o_Mux_117_o
                                                       eth0.e1/m100.u0/ethc0/tx_rmii1.tx0/Mmux_r_main_state[3]_X_108_o_Mux_117_o11
    OLOGIC_X0Y177.D1     net (fanout=2)        0.430   eth0.e1/m100.u0/ethc0/tx_rmii1.tx0/r_main_state[3]_X_108_o_Mux_117_o
    OLOGIC_X0Y177.CLK    Todck                 0.707   eth0.e1/m100.u0/ethc0/tx_rmii1.tx0/r_tx_en
                                                       eth0.e1/m100.u0/ethc0/tx_rmii1.tx0/r_tx_en
    -------------------------------------------------  ---------------------------
    Total                                      4.547ns (1.745ns logic, 2.802ns route)
                                                       (38.4% logic, 61.6% route)



__._,_.___



__,_._,___
Jan Andersson | 3 Apr 22:28 2014

Re: Can not compile the LEON3MP design with modelsim

Hello,

I think that the problem in the message that you replied to was that the
file was generated with MingW/MSYS - which is not supported.

Please check that you have set up the paths as described in section
2.4.2 of:

http://www.gaisler.com/products/grlib/grlib.pdf

(Is QuestaSim installed in c:\questasim64_10.0c?)

If the problem persists then please provide your full make.work file.

Best regards,
  Jan

On 4/2/14/w14 06:23, catten47@... wrote:
> 
> 
> Hello,
> 
> is there a solution to fix the problem? Because I am running in the same
> error message.
> Cygwin + Questasim 10.0.c + grlib-com-usbdc-1.1.0-b4116
> Exerpt from "make.work"
> # Generated by vmake version 2.2
> 
> # Define path to each library
> LIB_WORK = modelsim/grlib
> LIB_IEEE = /cygdrive/c/questasim64_10.0c/win64/../ieee
> LIB_STD = /cygdrive/c/questasim64_10.0c/win64/../std
> LIB_GRLIB = modelsim/grlib
> 
> # Define path to each design unit
> IEEE__numeric_std = $(LIB_IEEE)/numeric_std/_primary.dat
> IEEE__math_real = $(LIB_IEEE)/math_real/_primary.dat
> IEEE__std_logic_1164 = $(LIB_IEEE)/std_logic_1164/_primary.dat
> STD__textio = $(LIB_STD)/textio/_primary.dat
> GRLIB__xxor2__xxor_true = $(LIB_GRLIB)/xxor2/xxor_true.dat
> GRLIB__xxor2 = $(LIB_GRLIB)/xxor2/_primary.dat
> GRLIB__xxor1__xxor_regular = $(LIB_GRLIB)/xxor1/xxor_regular.dat
> GRLIB__xxor1 = $(LIB_GRLIB)/xxor1/_primary.dat
> 
> Best regards
> Carsten
> 

------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/LEON_SPARC/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/LEON_SPARC/join
    (Yahoo! ID required)

<*> To change settings via email:
    LEON_SPARC-digest@... 
    LEON_SPARC-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    LEON_SPARC-unsubscribe@...

<*> Your use of Yahoo Groups is subject to:
    https://info.yahoo.com/legal/us/yahoo/utos/terms/

Jan Heißwolf | 2 Apr 13:14 2014
Picon
Picon

AW: AW: L1-Cache Problem

Hello Magnus,

thank you for your response.

Reading the cache control register with cctrl returns 0x0081000f.

We use an operating system named OctoPOS, that was built in our project to
be used for a multi-core Leon3 design.
Here is a publication about it:
https://www4.cs.fau.de/~benjamin/documents/octopos_sfma2011.pdf
However, OctoPOS doesn't change the cctrl register.

Thank you and best regards,
Jan

-----Ursprüngliche Nachricht-----
Von: LEON_SPARC@...
[mailto:LEON_SPARC@...] Im
Auftrag von Magnus Hjorth
Gesendet: Mittwoch, 2. April 2014 10:32
An: LEON_SPARC@...
Betreff: Re: AW: [LEON_SPARC] L1-Cache Problem

Hello,

You could also check that your software is not running with snooping
disabled in the cache control register (use "cctrl" command in grmon to read
it out).

By the way, what operating system are you running?

/Magnus

On 04/02/2014 09:52 AM, Jan Heißwolf wrote:
> Hi Jan,
>
> thank you for the fast response!
>
> I just noticed that I messed up something with my configuration files 
> yesterday.
> I pasted an old configuration.
> This is the valid configuration:
>
> constant CFG_ICEN : integer := 1;
> constant CFG_ISETS : integer := 2;
> constant CFG_ISETSZ : integer := 8;
> constant CFG_ILINE : integer := 8;
> constant CFG_IREPL : integer := 1;
> constant CFG_ILOCK : integer := 0;
> constant CFG_ILRAMEN : integer := 0;
> constant CFG_ILRAMADDR : integer := 16#8E#; constant CFG_ILRAMSZ : 
> integer := 1; constant CFG_DCEN : integer := 1; constant CFG_DSETS : 
> integer := 2; constant CFG_DSETSZ : integer := 4; constant CFG_DLINE : 
> integer := 4; constant CFG_DREPL : integer := 1; constant CFG_DLOCK : 
> integer := 0; constant CFG_DSNOOP : integer := 2; --1 + 0 + 4*0; 
> constant CFG_DFIXED : integer := 16#0#; constant CFG_DLRAMEN : integer 
> := 1; constant CFG_DLRAMADDR : integer := 16#8F#; constant CFG_DLRAMSZ 
> : integer := 1; constant CFG_MMUEN : integer := 0;
>
> The CFG_DSNOOP is already set to "2". Do you think it makes sense to 
> test it with CFG_DSNOOP = 1?
> We use the commercial GRLIB version 1.1.0-b4116.
> In our design we use the Leon2 Memory Controller in combination with 
> an SSRAM.
> This is the instantiation of the controller:
>
> mctrl0 : mctrl generic map (hindex => CFG_SSRAM_HINDEX, pindex => 4, 
> ramaddr => 16#800#, rammask => 16#FF8#, romaddr => 16#B00#, rommask => 
> 16#FFF#, ioaddr => 16#C00#, iomask => 16#FF1#, srbanks => 1) port map 
> (rstn, clkm, memi, memo, ahbsi, ahbso(CFG_SSRAM_HINDEX), apbi, 
> apbo(4), wpo, open);
>
> Sorry for the confusion because of the wrong parameters.
>
> Thank you for your help!
>
> Best regards,
> Jan
>
> -----Ursprüngliche Nachricht-----
> Von: LEON_SPARC@...
[mailto:LEON_SPARC@...] Im 
> Auftrag von Jan Andersson
> Gesendet: Mittwoch, 2. April 2014 08:56
> An: LEON_SPARC@...
> Betreff: Re: [LEON_SPARC] L1-Cache Problem
>
> Hello,
>
> Which version of GRLIB are you running? What memory controller?
>
> Is the problem resolved if you set constant CFG_DSNOOP : integer := 2;?
>
> Best regards,
> Jan
>
> On 04/01/2014 10:02 PM, Jan Heißwolf wrote:
>  >
>  >
>  > Hello, everyone,
>  >
>  >
>  >
>  > In our multi-core LEON3MP configuration with 4 cores, we sometimes  
> >  > encounter situations where one of the L1 data caches contains 
> incorrect  >  > (probably stale) values. Most commonly, this issue 
> occurs if all four  >  > cores are competing for a spinlock. A typical 
> GRMON session after this  >  > problem occurred can be found here:
>  >
>  >
>  >
>  > http://pp.ipd.kit.edu/~mohr/invasic/l1-dcache-bug.txt
>  >
>  >
>  >
>  > In this case, three cores are asleep and the remaining core fails 
> to get  >  > a spinlock, which is implemented with one word. In the 
> log, the  >  > spinlock resides at address 0x801A6D08. A value of 0 
> indicates that the  >  > spinlock is free and a value of 1 indicates 
> that the spinlock is taken.
>  >
>  > As can be seen in the instruction trace, the L1 cache continues to  
> >  > deliver the value 1 (spinlock taken) for this address (see 
> results of  >  > "ld [%i0 + 0x4]"). However, manual inspection of this 
> address using  >  > "mem" shows that its value is actually 0 (spinlock 
> free). After  >  > manually disabling the data cache using "dcache 0", 
> the core  >  > successfully acquires the spinlock and execution 
> continues.
>  >
>  >
>  >
>  > According to the cache configuration register content, the cache  >  
> > is configured as follows: 0x81000f.
>  >
>  >
>  >
>  > This is the hardware cache-configuration which is used:
>  >
>  > constant CFG_ICEN : integer := 1;
>  >
>  > constant CFG_ISETS : integer := 2;
>  >
>  > constant CFG_ISETSZ : integer := 8;  >  > constant CFG_ILINE : 
> integer := 8;  >  > constant CFG_IREPL : integer := 1;  >  > constant 
> CFG_ILOCK : integer := 0;  >  > constant CFG_ILRAMEN : integer := 0;  
> >  > constant CFG_ILRAMADDR: integer := 16#8E#;  >  > constant 
> CFG_ILRAMSZ : integer := 1;  >  > constant CFG_DCEN : integer := 1;  >  
> > constant CFG_DSETS : integer := 2;  >  > constant CFG_DSETSZ : 
> integer := 4;  >  > constant CFG_DLINE : integer := 4;  >  > constant 
> CFG_DREPL : integer := 1;  >  > constant CFG_DLOCK : integer := 0;  >  
> > constant CFG_DSNOOP : integer := 1 + 0 + 4*0;  >  > constant 
> CFG_DFIXED : integer := 16#0#;  >  > constant CFG_DLRAMEN : integer := 
> 1;  >  > constant CFG_DLRAMADDR: integer := 16#8F#;  >  > constant 
> CFG_DLRAMSZ : integer := 4;  >  > constant CFG_MMUEN : integer := 0;  
> >  >  >  > Could there be an error in our configuration?
>  >
>  > What could we do to solve this issue?
>  >
>  >
>  >
>  > Thank you!
>  >
>  >
>  >
>  > Best regards,
>  >
>  > Manuel and Jan
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>
> ------------------------------------
>
> Yahoo Groups Links
>
> 

------------------------------------

Yahoo Groups Links

------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/LEON_SPARC/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/LEON_SPARC/join
    (Yahoo! ID required)

<*> To change settings via email:
    LEON_SPARC-digest@... 
    LEON_SPARC-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    LEON_SPARC-unsubscribe@...

<*> Your use of Yahoo Groups is subject to:
    https://info.yahoo.com/legal/us/yahoo/utos/terms/

pafbat00 | 2 Apr 14:46 2014
Picon
Picon

Use of apbuart.h



Hi, I am working with RTEMS 4.10 version from Gaisler distribution over a LEON3 in a custom board. I have been trying to configure my UART to be accessed by apbuart.c driver instead of cons.c driver. Do I have to recompile RTEMs sources in order to be capable of using this driver instead of "cons" one?

pafbat.

__._,_.___


__,_._,___
Jan Heißwolf | 1 Apr 22:02 2014
Picon
Picon

L1-Cache Problem



Hello, everyone,

 

In our multi-core LEON3MP configuration with 4 cores, we sometimes

encounter situations where one of the L1 data caches contains incorrect

(probably stale) values.  Most commonly, this issue occurs if all four

cores are competing for a spinlock.  A typical GRMON session after this

problem occurred can be found here:

 

http://pp.ipd.kit.edu/~mohr/invasic/l1-dcache-bug.txt

 

In this case, three cores are asleep and the remaining core fails to get

a spinlock, which is implemented with one word.  In the log, the

spinlock resides at address 0x801A6D08.  A value of 0 indicates that the

spinlock is free and a value of 1 indicates that the spinlock is taken.

  As can be seen in the instruction trace, the L1 cache continues to

deliver the value 1 (spinlock taken) for this address (see results of

"ld  [%i0 + 0x4]").  However, manual inspection of this address using

"mem" shows that its value is actually 0 (spinlock free).  After

manually disabling the data cache using "dcache 0", the core

successfully acquires the spinlock and execution continues.

 

According to the cache configuration register content, the cache

is configured as follows: 0x81000f.

 

This is the hardware cache-configuration which is used:

  constant CFG_ICEN : integer := 1;

  constant CFG_ISETS : integer := 2;

  constant CFG_ISETSZ : integer := 8;

  constant CFG_ILINE : integer := 8;

  constant CFG_IREPL : integer := 1;

  constant CFG_ILOCK : integer := 0;

  constant CFG_ILRAMEN : integer := 0;

  constant CFG_ILRAMADDR: integer := 16#8E#;

  constant CFG_ILRAMSZ : integer := 1;

  constant CFG_DCEN : integer := 1;

  constant CFG_DSETS : integer := 2;

  constant CFG_DSETSZ : integer := 4;

  constant CFG_DLINE : integer := 4;

  constant CFG_DREPL : integer := 1;

  constant CFG_DLOCK : integer := 0;

  constant CFG_DSNOOP : integer := 1 + 0 + 4*0;

  constant CFG_DFIXED : integer := 16#0#;

  constant CFG_DLRAMEN : integer := 1;

  constant CFG_DLRAMADDR: integer := 16#8F#;

  constant CFG_DLRAMSZ : integer := 4;

  constant CFG_MMUEN : integer := 0;

 

Could there be an error in our configuration?

What could we do to solve this issue?

 

Thank you!

 

Best regards,

Manuel and Jan

 

 

 



__._,_.___


__,_._,___
alhawaj | 31 Mar 00:02 2014
Picon

Stalling Pipeline in-case of JMPL, RETT



Hello, everyone,

I was going through the VHDL description of LEON3 to understand most of the signals in the design. As I was trying to figure out the branch mechanism in LEON3, I stumbled upon the JMPL and RETT special treatment. Basically, in the case of JMP or RETT, the nPC will be determined in the execute stage. Therefore, the pipeline must be stalled, if we don't want to speculate on the next PC. I saw that LEON3 uses inull to determine when to hold PC and insert bubbles into the next stages, using annul bit in the control registers. So far, good ...

While investigating how the inull is being generated, I saw the following cases (in function ra_inull_gen) :

    de_inull := '0';
    if ((v.e.jmpl or v.e.ctrl.rett) and not v.e.ctrl.annul and not (r.e.jmpl and not r.e.ctrl.annul)) = '1' then de_inull := '1'; end if;
    if ((v.a.jmpl or v.a.ctrl.rett) and not v.a.ctrl.annul and not (r.a.jmpl and not r.a.ctrl.annul)) = '1' then de_inull := '1'; end if;

What I understand is that: while there is a valid JMPL and/or RETT instruction either going into RegAcc stage or Execute stage, keep stalling the pipeline and holding onto the instruction after JMPL/RETT; this part makes sense.

However, the other part of the if statement doesn't make any sense. We basically are checking that there are no valid JMPL instructions already either in RegAcc and/or RETT stage. However, if that's the case, then the incoming annul would be false anyways. Also, even if this accounts for some corner special cases that I've missed, I don't understand why we are checking for JMPL only and not for both.

What I am saying basically is that:

(not v.e.ctrl.annul) is zero whenever (not (r.e.jmpl and not r.e.ctrl.annul)) is zero

Because, by definition, whatever follows a JMPL has to be a bubble. Also, why are we checking for JMPL only and not for both JMPL and RETT, since both have the same execution path in the pipleline (through ex_jump signal)?

Thanks!

Regards,
Khalid


__._,_.___


__,_._,___
mauro.cipollone | 29 Mar 05:15 2014
Picon

Question about Snapgear 2.6 statically and dynamically linked apps



Hi all, I'm here again to ask you a question about a subject which I cannot understand well. I've been working with snapgear 2.6 linux running on my leon3mmu system on a Digilent Atlys board. I read in the snapgear-manual-1.0.39.pdf (under section 3.1) that "Linux 2.6 cannot run without MMU, whereas μCLinux runs without MMU". And then I read on http://www.gaisler.com/index.php/products/operating-systems/linux that "The linux-2.6.21.1 kernel can use the uClibc-0.9.28.2 library for statically linked applications, or glibc-2.3.2 for dynamically linked applications".
I've trying to figure out why the uclibc is used to create statically linked apps and the glibc is used to create dinamically linked apps. After some research I ended up with the following conclusion: "uclibc is used to create statically linked apps instead of dinamically linked because uclibc is used on MMU-less systems, on which make a dynamically linking structure is harder, so linux 2.6 with uclibc is intended to be used on MMU-less systems...". But this reasoning contradicts the manual, so I don't understand well why uclibc cannot be used to develop dynamically linked apps.
Sorry if the reason is quite obvious and I cannot see it, I'm quite new on this topic. I know as well that snapgear is old and I should be working with Linuxbuild (which I am right now) but I have to write a paper for my work and I don't want to write something loose.

Thanks in advance

Mauro  

__._,_.___


__,_._,___

Gmane