LOGIN   :::   RECOVER PASS   :::   GET ACCOUNT    
Browse
  • Projects
  • Code (CVS)
  • Forums
  • News
  • Articles
  • Polls
  •  
    OpenCores
  • FAQ
  • CVS HowTo
  • Mission
  • Media
  • Tools
  • Advertise
  • Mirrors
  • Logos
  • Contact us
  • Find Resources
  • Job Opportunity
  •  
    Tools
  • Search
      
  • Download Cores (CVSGet)
  •  
    More
  • Wishbone
  • Perlilog
  • EDA tools
  • OpenTech CD
  •  
    Navigation: All forums > Openrisc > Message List > Message Post

    Message

    Reply | Reply all
    Date Prev | Date Next | Thread Prev | Thread Next Date Index | Thread Index

    From: Zied BEN SALEM<zied.bensalem@g...>
    Date: Mon Feb 25 07:33:50 CET 2008
    Subject: [openrisc] Re: OpenRISC Digest, Vol 50, Issue 6
    Top
    Hi all,

    I am an associate professor in an engineering school in Tunisia. We are
    trying to integrate OPEN RISC in the official courses. Thus we need to do
    some basic experiments (at least simulating linux with OR1K). I consulted
    many tutorials, all seems to be old and many files suggested does not exist
    in the actual CVS.

    So, first of all I need to know if somone has tried the 0R1K in Debian or
    Ubuntu. The we would be very grateful if somone could provide us a complete
    package of The OR1k or OR1K2 simulation kit with a complete tutorial.

    Best regards.

    Zied BEN SALEM PhD.Eng.


    2008/2/23, attachment-0001.htm>
    > Content-Type: text/plain; charset=us-ascii
    >
    >
    > i don't figure out the printf either.
    > so i delete all printf in my code...
    >
    >
    > Rahul Wagh wrote:
    > >
    > > Hi,
    > >
    > > As you might have seen, when we say printf("....") in a OR1k testcase
    > > written in C, it calls the printf routine written in support.c file.
    > That
    > > does not give the actual printing of the message within "..." though.
    > > Anybody has tried that in OR1k ? Any suggestions / pointers ?
    > >
    > > At my end, I figured out that the GPR R3 gets the starting address of
    > the
    > > memory location where the message in printf is stored. Using that, I
    > wrote
    > > a
    > > small code in verilog monitor (or1200_monitor.v) to access the memory
    > > (till
    > > you get an ASCII equivalent of NULL or something like that) and display
    > > the
    > > things in %c format to get the message. However, this helps only for
    > > 'pure-text' type messages. It does not work for messages like the > > following > > : > > > > printf("Register value = %x",reg_value); > > > > Can anybody throw some light on how to do this ? (How does one track the > > location of the arguments passed to the printf statement ? etc..) > > > > Thanks, > > > > Rahul. > > > > _______________________________________________ > > attachment-0001.htm > > > > > > -- > View this message in context: > attachment-0001.htm > Sent from the OpenCores - RISC mailing list archive at Nabble.com. > > > > ------------------------------ > > Message: 3 > Date: Thu, 21 Feb 2008 01:06:17 -0800 (PST) > From: yueng <attachment-0001.htm> > Subject: Re: [openrisc] or1ksim 's question > To: attachment-0001.htm > Message-ID: <attachment-0001.htm> > Content-Type: text/plain; charset=us-ascii > > > thanks > the CPU core you mentioned BA22 /BA14 is opensource free or commercial? > > best regard > yeung > > > Matjaz Breskvar-5 wrote: > > > > Hi Yeung, > > The or1ksim cycles count is not very accurate, and even if you set the > > right > > memory delays it is just a rough esstimation. > > Having said that, the toolchain for OpenRISC is very unoptimized and the > > OpenRISC itself is lacking in some areas. To improve all that the Beyond > > Semiconductor was founded by the creators of OpenRISC. First we have > > cosiderably optimized the OpenRISC RTL, and the result is Beyond BA12 > > processor, fully backwards compatible. Things that could not be improved > > due > > to instruction set were addressed with Beyond BA22 which features the > > world > > highest code density and has ~55% clock-for-clock performance increase > > comparing to OpenRISC (with optimized toolchain). > > > > Another interesting product is BA14 processor, an out-of-order dual > issue > > processor, which offers ~10x performance comparing to OpenRISC. > > > > Currently we are in discussion how to offer all this developments to > > comunity in a way not to disturb the founding such development requires. > > Hopefully things get wrapped up soon. > > > > For more info on OpenRISC compatible processors (in the sense that only > > sofware recompile is needed) and peripherals you may visit our website > at: > > > > attachment-0001.htm > > > > Yeung, please feel free to contact me, if you'd like to evaluate > > performance > > of our processors with optimized toolchains against ARM. Te results will > > be > > much more favorable. > > > > best regards, > > matjaz. > > > > > > > > * yueng (attachment-0001.htm) wrote: > >> > >> thanks > >> > >> i just want to compare or1k's perfomance with arm7 or arm9, so i use > some > >> algorithm ,for example > >> jpeg decode run both on or1k and arm. to see which one use less cycles. > >> and my result is or1ksim use 300M cycle and 200M instruction to finish > a > >> 320x240 jpegdecode compared > >> with arm7 50M cycle and 40M instruction. > >> > >> > >> > >> Dimitri?s Orfanos wrote: > >> > > >> > Oh, and something else. I am not a maintainer of this project but > I've > >> > involved because of my university has put me an assignment(actually a > >> > master thesis). So by reading the code of the or1ksim0.2.0 I have > >> > concluded that there is no good measuring of cycles so I've done > >> > something else. I've set on my own some CPI(clocks per instruction) > and > >> > with little scripting I can see which commands are executed (from the > >> > executed.log) and how many times these commands are executed and I > >> > calculate the total cycles of my own. For example I've set that the > >> > "l.and" command uses 1 cycle if with my little script sees that there > >> > are 3 "l.and" I measure 3*1 total cycles. The simulator uses a > >> scheduler > >> > which every n cycles tries to communicate with virtual devices that > are > >> > defined in the sim.cfg like keyboard, uart, etc . These cycles are > also > >> > added in the simulation cycles, so there is not so accurate. If you > >> want > >> > to use the simulator for cycle counting do something similar with me > >> > make a little script and count the commands from the executed.log . > If > >> > you just want to use the simulator to run programs then you don't > need > >> > to count cycles. > >> > DO > >> > > >> > yueng wrote: > >> >> I change the sim.cfg , mem read and write both delay 1. > >> >> i run jpeg decode in the or1ksim > >> >> the result is > >> >> 310,200,242 cycles, 171,816,396 instructions > >> >> compare with arm7 it use only 56,000,000 cycle, and 40,000,000 > >> >> instructions > >> >> > >> >> i remember that i read or1ksim is about 90% cycle accurate > somewhere, > >> >> same jpeg decode C code ,why or1ksim use so many instructions? and > so > >> >> many > >> >> cycles. > >> >> > >> >> > >> >> thank you > >> >> > >> > _______________________________________________ > >> > attachment-0001.htm > >> > > >> > > >> > >> -- > >> View this message in context: > >> attachment-0001.htm > >> Sent from the OpenCores - RISC mailing list archive at Nabble.com. > >> > >> _______________________________________________ > >> attachment-0001.htm > > _______________________________________________ > > attachment-0001.htm > > > > > > -- > View this message in context: > attachment-0001.htm > Sent from the OpenCores - RISC mailing list archive at Nabble.com. > > > > ------------------------------ > > Message: 4 > Date: Thu, 21 Feb 2008 14:27:43 +0200 > From: attachment-0001.htm > Subject: Re: [openrisc] Printf using OR1K C test and verilog. > To: attachment-0001.htm > Message-ID: <attachment-0001.htm> > Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; > format="flowed" > > Hi, > > Maybe this helps: > www.da.isy.liu.se/courses/tsea02 > lab0-4 > hw_sw\lab0-4\hw\monitor\firmware\src\printf.c > Copyright 2001, 2002 Georges Menie (www.menie.org) > > Regards, > Laurentiu Duca > attachment-0001.htm > > Quoting Rahul Wagh <attachment-0001.htm>: > > > Hi, > > > > As you might have seen, when we say printf("....") in a OR1k testcase > > written in C, it calls the printf routine written in support.c file. > That > > does not give the actual printing of the message within "..." though. > > Anybody has tried that in OR1k ? Any suggestions / pointers ? > > > > At my end, I figured out that the GPR R3 gets the starting address of > the > > memory location where the message in printf is stored. Using that, I > wrote a > > small code in verilog monitor (or1200_monitor.v) to access the memory > (till > > you get an ASCII equivalent of NULL or something like that) and display > the > > things in %c format to get the message. However, this helps only for > > 'pure-text' type messages. It does not work for messages like the > following > > : > > > > printf("Register value = %x",reg_value); > > > > Can anybody throw some light on how to do this ? (How does one track the > > location of the arguments passed to the printf statement ? etc..) > > > > Thanks, > > > > Rahul. > > > > _______________________________________________ > > attachment-0001.htm > > > > -- > > This message has been scanned for viruses and > > dangerous content by MailScanner, and is > > believed to be clean. > > > > > > > > -- > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > > > ------------------------------ > > Message: 5 > Date: Thu, 21 Feb 2008 14:33:50 +0200 > From: attachment-0001.htm > Subject: Re: [openrisc] or1ksim 's question > To: Pier Francesco Maria Santi <pfm.santi@e...> > Cc: openrisc@o... > Message-ID: <20080221143350.vii0kq4n40gow008@m...> > Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; > format="flowed" > > Hi, > > Maybe this helps: > > http://www.nabble.com/Re:-how-to-run-gcc-compiler-independently-for-generation%09machine-code-for-or1k-td14948162.html > > http://www.meansoffreedom.org/opencores.html > http://www.eecg.utoronto.ca/~jarvin/or32/ > http://www.asisi.co.uk/openrisc > http://www.opencores.org/projects.cgi/web/or1k/gnu_toolchain_port > http://www.opencores.org/projects.cgi/web/or1k/architectural_simulator > > I have ported lab1 from > www.da.isy.liu.se/courses/tsea02 > to Digilent Nexys Board. > > > Regards, > Laurentiu-Cristian Duca > http://prof.cs.pub.ro/~duca > > > Quoting Pier Francesco Maria Santi <pfm.santi@e...>: > > > Hi everybody. > > Anyone have a Windows complete toolchain for OPENRISC? > > > > yueng ha scritto: > >> I change the sim.cfg , mem read and write both delay 1. > >> i run jpeg decode in the or1ksim > >> the result is 310,200,242 cycles, 171,816,396 instructions > >> compare with arm7 it use only 56,000,000 cycle, and 40,000,000 > instructions > >> > >> i remember that i read or1ksim is about 90% cycle accurate somewhere, > >> same jpeg decode C code ,why or1ksim use so many instructions? and so > many > >> cycles. > >> > >> > >> thank you > >> > > > > _______________________________________________ > > http://www.opencores.org/mailman/listinfo/openrisc > > > > -- > > This message has been scanned for viruses and > > dangerous content by MailScanner, and is > > believed to be clean. > > > > -- > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > > > ------------------------------ > > Message: 6 > Date: Fri, 22 Feb 2008 00:31:15 +0100 (CET) > From: rich_daddio@y... > Subject: Re: [openrisc] Printf using OR1K C test and verilog. > To: openrisc@o... > Message-ID: <20080221233115.9A250F00116@w...> > > Hi, > I am not sure if this is what you are looking for but take a look at > OpenRISC 1000 Architecture Manual under "Function Calling Sequence" > and the table of registers, and that might help you. > > http://www.opencores.org/cvsweb.shtml/or1k/docs/openrisc_arch.pdf > > > HTH & Best Regards, > > Rich d > ----- Original Message ----- > From: Rahul Wagh<rahul.wagh@m...> > To: > Date: Wed Feb 20 09:14:25 CET 2008 > Subject: [openrisc] Printf using OR1K C test and verilog. > > > Hi, > > > > As you might have seen, when we say printf("....") in a > > OR1k testcase > > written in C, it calls the printf routine written in support.c > > file. That > > does not give the actual printing of the message within > > "..." though. > > Anybody has tried that in OR1k ? Any suggestions / pointers ? > > At my end, I figured out that the GPR R3 gets the starting address > > of the > > memory location where the message in printf is stored. Using that, > > I wrote a > > small code in verilog monitor (or1200_monitor.v) to access the > > memory (till > > you get an ASCII equivalent of NULL or something like that) and > > display the > > things in %c format to get the message. However, this helps only > > for > > 'pure-text' type messages. It does not work for messages like the > > following > > : > > printf("Register value = %x",reg_value); > > Can anybody throw some light on how to do this ? (How does one > > track the > > location of the arguments passed to the printf statement ? etc..) > > Thanks, > > Rahul. > > > > > > > ------------------------------ > > Message: 7 > Date: Thu, 21 Feb 2008 23:53:12 -0800 (PST) > From: Yuping <3031133033@z...> > Subject: [openrisc] or1k's simulation > To: openrisc@o... > Message-ID: <15628960.post@t...> > Content-Type: text/plain; charset=us-ascii > > > hi: > I installed the toolchain :drp-0.6 toolchain (or32-elf-**) and goto > orp_soc/sw/support/ fold and do make; next, I goto orp_soc/sw/basic/ fold > and do make, it doesnot work, error messages are: > > or32-elf-ld -T ../support/orp.ld basic.o ../support/reset-nocache.o -o > basic-nocache.or32 ../support/libsupport.a > basic.o: In function `_T7': > basic.S:(.text+0x54c): undefined reference to `_exit' > ../support/reset-nocache.o: In function `_start': > reset.S:(.text+0xec): undefined reference to `_reset' > ../support/libsupport.a(support.o): In function `_read_timer': > support.c:(.text+0x94): undefined reference to `_gettimeofday' > support.c:(.text+0xa4): undefined reference to `___mulsi3' > ../support/libsupport.a(support.o): In function `_report': > support.c:(.text+0xe0): undefined reference to `_printf' > make: *** [basic-nocache] Error 1 > > > Does anybody encounter this problem? I want to generate *.hex file and do > hardware simulation, pls help me > -- > View this message in context: > http://www.nabble.com/or1k%27s-simulation-tp15628960p15628960.html > Sent from the OpenCores - RISC mailing list archive at Nabble.com. > > > > ------------------------------ > > Message: 8 > Date: Fri, 22 Feb 2008 02:00:48 -0600 > From: "James Cotton" <peabody124@g...> > Subject: [openrisc] debugger doesn't return from stepi > To: "List about OpenRISC project" <openrisc@o...> > Message-ID: > <a08e8e760802220000y6d165dbcu62ecb66e1855a2e2@m...> > Content-Type: text/plain; charset=ISO-8859-1 > > I'm trying to get linux to boot up on my spartan 3e / or1200 system. > I can load hello-world through the jtag into SDRAM and receive it just > fine. However, when I try and load up my kernel it loads fine, and > when I look at the instructions about to be executed they are all > correct. However, around when it tries to access the uart (as I said > hello world works fine, so I know the address is right and working) > gdb never returns after the stepi instruction. Specifically it's a > l.sb to that register (when I've caught it). Even more strangely, > when I then load hello-world it also locks up in a similar way. > > So my question is, what sort of errors will cause the debug interface > not to return from a stepi command. Would this be characteristic of > something being set wrong with a data/instruction cache? I can > simulate the same code (in iverilog and or1ksim) and don't see a > problem. > > > ------------------------------ > > _______________________________________________ > OpenRISC mailing list > OpenRISC@o... > http://www.opencores.org/mailman/listinfo/openrisc > > > End of OpenRISC Digest, Vol 50, Issue 6 > *************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums.cgi/openrisc/attachments/20080225/99261c5d/attachment-0001.htm

     
    Copyright (c) 1999 OPENCORES.ORG. All rights reserved.