OpenCores

OpenCores

or1ksim simulator question - endianess issue confirmed

no use

no use

1/1

no use

no use

or1ksim simulator question - endianess issue confirmed by Unknown on Oct 7, 2005			Not available!
Hi, I am not sure that if I made the change at the correct place. But by factor in the ENDIAN issue in the addprogram routine, my simulator works. void addprogram(oraddr_t address, uint32_t insn, int* breakpoint) { int vaddr = (!runtime.sim.filename) ? translate(address,breakpoint) : translate(freemem,breakpoint); /* We can't have set_program32 functions since it is not gauranteed that the * section we're loading is aligned on a 4-byte boundry / /ZQI patch/ #ifdef WORDS_BIGENDIAN set_program8 (vaddr + 3, (insn >> 24) & 0xff); set_program8 (vaddr + 2, (insn >> 16) & 0xff); set_program8 (vaddr + 1, (insn >> 8) & 0xff); set_program8 (vaddr, insn & 0xff); #else set_program8 (vaddr, (insn >> 24) & 0xff); set_program8 (vaddr + 1, (insn >> 16) & 0xff); set_program8 (vaddr + 2, (insn >> 8) & 0xff); set_program8 (vaddr + 3, insn & 0xff); #endif It might have something to do with how the elf files are generated. Thanks -Charles [q] -----Original Message----- From: <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">openrisc-bounces at opencores.org</A> [mailto:<A HREF="http://www.opencores.org/mailman/listinfo/openrisc">openrisc-bounces at opencores.org</A>]On Behalf Of Charles Qi Sent: Thursday, October 06, 2005 9:44 AM To: 'List about OpenRISC project' Subject: RE: [openrisc] or1ksim simulator question - built fine and doesn't run Hi nog, Thanks for looking into this. It is a big-endian machine. Actually that might be the problem. Because I tried to run one instruction with the simulator and it generates an invalid instruction exception. (sim) run 1 00000104: : e81fe2d7 <invalid> (executed) [cycle 20, #2] 00018f40: : 00000000 l.j 0x0 (next insn) I looked at the objdump of dhry and it shows f0000104: d7 e2 1f e8 l.sw 0xffffffe8(r2),r3 Notice that d7e21fe8 is completely reversed. The fact that I don't have any exception handler causes all the subsequent instructions to be l.j 0x0. How do you recommend fix it? -Charles [q]> I downloaded the tar ball of or1k and built binutils, gcc and gdb for > or32 successfully for SunOS sun4u sparc SUNW,Ultra-80.[/q] Is this a big endian processor by chance? [q]> When I actually try to run the simulation like [q] >or32-uclinux-sim -i testbench/dhry[/q] All device instantiation (like memory, uart, ethernet, etc.) are done in a configuration file. For a detailed description of its format see sim.cfg in the top level simulator directory. Most of the testbenches use the testbench/default.cfg (which is a little different to the default config file). Other tests have their own config files, like the mmu uses testbench/mmu.cfg. You can tell the sim which config file to use with the `-f' switch. Thus your example, should, correctly, have been or32-uclinux-sim -i -f testbench/default.cfg testbench/dhry [q]> > I am wondering if there is a HowTo that describes how to use the > simulator.[/q] Unfourtonatly there is none. nog. _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A> _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A> [/q] Hi, I am not sure that if I made the change at the correct place. But by factor in the ENDIAN issue in the addprogram routine, my simulator works. void addprogram(oraddr_t address, uint32_t insn, int breakpoint) { int vaddr = (!runtime.sim.filename) ? translate(address,breakpoint) : translate(freemem,breakpoint); /* We can't have set_program32 functions since it is not gauranteed that the * section we're loading is aligned on a 4-byte boundry / /ZQI patch*/ #ifdef WORDS_BIGENDIAN set_program8 (vaddr + 3, (insn >> 24) & 0xff); set_program8 (vaddr + 2, (insn >> 16) & 0xff); set_program8 (vaddr + 1, (insn >> 8) & 0xff); set_program8 (vaddr, insn & 0xff); #else set_program8 (vaddr, (insn >> 24) & 0xff); set_program8 (vaddr + 1, (insn >> 16) & 0xff); set_program8 (vaddr + 2, (insn >> 8) & 0xff); set_program8 (vaddr + 3, insn & 0xff); #endif It might have something to do with how the elf files are generated. Thanks -Charles -----Original Message----- From: openrisc-bounces at opencores.org [mailto:openrisc-bounces at opencores.org]On Behalf Of Charles Qi Sent: Thursday, October 06, 2005 9:44 AM To: 'List about OpenRISC project' Subject: RE: [openrisc] or1ksim simulator question - built fine and doesn't run Hi nog, Thanks for looking into this. It is a big-endian machine. Actually that might be the problem. Because I tried to run one instruction with the simulator and it generates an invalid instruction exception. (sim) run 1 00000104: : e81fe2d7 (executed) [cycle 20, #2] 00018f40: : 00000000 l.j 0x0 (next insn) I looked at the objdump of dhry and it shows f0000104: d7 e2 1f e8 l.sw 0xffffffe8(r2),r3 Notice that d7e21fe8 is completely reversed. The fact that I don't have any exception handler causes all the subsequent instructions to be l.j 0x0. How do you recommend fix it? -Charles > I downloaded the tar ball of or1k and built binutils, gcc and gdb for > or32 successfully for SunOS sun4u sparc SUNW,Ultra-80. Is this a big endian processor by chance? > When I actually try to run the simulation like >or32-uclinux-sim -i testbench/dhry All device instantiation (like memory, uart, ethernet, etc.) are done in a configuration file. For a detailed description of its format see sim.cfg in the top level simulator directory. Most of the testbenches use the testbench/default.cfg (which is a little different to the default config file). Other tests have their own config files, like the mmu uses testbench/mmu.cfg. You can tell the sim which config file to use with the `-f' switch. Thus your example, should, correctly, have been or32-uclinux-sim -i -f testbench/default.cfg testbench/dhry > > I am wondering if there is a HowTo that describes how to use the > simulator. Unfourtonatly there is none. nog. _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc

or1ksim simulator question - endianess issue confirmed by Unknown on Oct 7, 2005			Not available!
[q] Hi, I am not sure that if I made the change at the correct place. But by factor in the ENDIAN issue in the addprogram routine, my simulator works. void addprogram(oraddr_t address, uint32_t insn, int* breakpoint) { int vaddr = (!runtime.sim.filename) ? translate(address,breakpoint) : translate(freemem,breakpoint); /* We can't have set_program32 functions since it is not gauranteed that the * section we're loading is aligned on a 4-byte boundry / /ZQI patch/ #ifdef WORDS_BIGENDIAN set_program8 (vaddr + 3, (insn >> 24) & 0xff); set_program8 (vaddr + 2, (insn >> 16) & 0xff); set_program8 (vaddr + 1, (insn >> 8) & 0xff); set_program8 (vaddr, insn & 0xff); #else set_program8 (vaddr, (insn >> 24) & 0xff); set_program8 (vaddr + 1, (insn >> 16) & 0xff); set_program8 (vaddr + 2, (insn >> 8) & 0xff); set_program8 (vaddr + 3, insn & 0xff); #endif[/q] Your change is correct. Perhaps you can submit a unified diff? Also, the simmem_{read,write}{16,8} functions in peripheral/memory.c need to be patched to handle big endian correctly. There is testbench/mem_test, which you can use to verify that everything is ok with endianess. [q] > I downloaded the tar ball of or1k and built binutils, gcc and gdb for > or32 successfully for SunOS sun4u sparc SUNW,Ultra-80.[/q] Another stupid question, is this a 32-bit or 64-bit processor? nog. Hi, I am not sure that if I made the change at the correct place. But by factor in the ENDIAN issue in the addprogram routine, my simulator works. void addprogram(oraddr_t address, uint32_t insn, int breakpoint) { int vaddr = (!runtime.sim.filename) ? translate(address,breakpoint) : translate(freemem,breakpoint); /* We can't have set_program32 functions since it is not gauranteed that the * section we're loading is aligned on a 4-byte boundry / /ZQI patch*/ #ifdef WORDS_BIGENDIAN set_program8 (vaddr + 3, (insn >> 24) & 0xff); set_program8 (vaddr + 2, (insn >> 16) & 0xff); set_program8 (vaddr + 1, (insn >> 8) & 0xff); set_program8 (vaddr, insn & 0xff); #else set_program8 (vaddr, (insn >> 24) & 0xff); set_program8 (vaddr + 1, (insn >> 16) & 0xff); set_program8 (vaddr + 2, (insn >> 8) & 0xff); set_program8 (vaddr + 3, insn & 0xff); #endif Your change is correct. Perhaps you can submit a unified diff? Also, the simmem_{read,write}{16,8} functions in peripheral/memory.c need to be patched to handle big endian correctly. There is testbench/mem_test, which you can use to verify that everything is ok with endianess. > I downloaded the tar ball of or1k and built binutils, gcc and gdb for > or32 successfully for SunOS sun4u sparc SUNW,Ultra-80. Another stupid question, is this a 32-bit or 64-bit processor? nog.

or1ksim simulator question - endianess issue confirmed by Unknown on Oct 7, 2005			Not available!
Hi Gyvrgy , Thanks again. I will try to fix the similar issue peripheral/memory.c. I see your point of checking 32-b vs. 64-b. My system is a 64-bit capable 4-MP UltraSPARC-II with Solaris. But I think the tool chain as 32-bit. I am not sure that could have made a difference. If it does, then even the 'addprogram' itself may not be sufficient to fix the problem because it only handles 32-bit instruction at a time. I can see this become an issue even on 64-bit little endian machine like Athlon. This is where you will see a hardware engineer's (like myself) knowledge fall short. I will discuss with you on generating the unified diff once I get all the tests working. I will try to use testbench/test command to run through all of the tests available. -Charles -----Original Message----- From: <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">openrisc-bounces at opencores.org</A> [mailto:<A HREF="http://www.opencores.org/mailman/listinfo/openrisc">openrisc-bounces at opencores.org</A>] On Behalf Of Gyvrgy 'nog' Jeney Sent: Thursday, October 06, 2005 11:31 PM To: List about OpenRISC project Subject: Re: [openrisc] or1ksim simulator question - endianess issue confirmed [q] Hi, I am not sure that if I made the change at the correct place. But by factor in the ENDIAN issue in the addprogram routine, my simulator works. void addprogram(oraddr_t address, uint32_t insn, int* breakpoint) { int vaddr = (!runtime.sim.filename) ? translate(address,breakpoint) : translate(freemem,breakpoint); /* We can't have set_program32 functions since it is not gauranteed that the * section we're loading is aligned on a 4-byte boundry / /ZQI patch/ #ifdef WORDS_BIGENDIAN set_program8 (vaddr + 3, (insn >> 24) & 0xff); set_program8 (vaddr + 2, (insn >> 16) & 0xff); set_program8 (vaddr + 1, (insn >> 8) & 0xff); set_program8 (vaddr, insn & 0xff); #else set_program8 (vaddr, (insn >> 24) & 0xff); set_program8 (vaddr + 1, (insn >> 16) & 0xff); set_program8 (vaddr + 2, (insn >> 8) & 0xff); set_program8 (vaddr + 3, insn & 0xff); #endif[/q] Your change is correct. Perhaps you can submit a unified diff? Also, the simmem_{read,write}{16,8} functions in peripheral/memory.c need to be patched to handle big endian correctly. There is testbench/mem_test, which you can use to verify that everything is ok with endianess. [q] > I downloaded the tar ball of or1k and built binutils, gcc and gdb > for or32 successfully for SunOS sun4u sparc SUNW,Ultra-80.[/q] Another stupid question, is this a 32-bit or 64-bit processor? nog. _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A> Hi Gyvrgy , Thanks again. I will try to fix the similar issue peripheral/memory.c. I see your point of checking 32-b vs. 64-b. My system is a 64-bit capable 4-MP UltraSPARC-II with Solaris. But I think the tool chain as 32-bit. I am not sure that could have made a difference. If it does, then even the 'addprogram' itself may not be sufficient to fix the problem because it only handles 32-bit instruction at a time. I can see this become an issue even on 64-bit little endian machine like Athlon. This is where you will see a hardware engineer's (like myself) knowledge fall short. I will discuss with you on generating the unified diff once I get all the tests working. I will try to use testbench/test command to run through all of the tests available. -Charles -----Original Message----- From: openrisc-bounces at opencores.org [mailto:openrisc-bounces at opencores.org] On Behalf Of Gyvrgy 'nog' Jeney Sent: Thursday, October 06, 2005 11:31 PM To: List about OpenRISC project Subject: Re: [openrisc] or1ksim simulator question - endianess issue confirmed Hi, I am not sure that if I made the change at the correct place. But by factor in the ENDIAN issue in the addprogram routine, my simulator works. void addprogram(oraddr_t address, uint32_t insn, int breakpoint) { int vaddr = (!runtime.sim.filename) ? translate(address,breakpoint) : translate(freemem,breakpoint); /* We can't have set_program32 functions since it is not gauranteed that the * section we're loading is aligned on a 4-byte boundry / /ZQI patch*/ #ifdef WORDS_BIGENDIAN set_program8 (vaddr + 3, (insn >> 24) & 0xff); set_program8 (vaddr + 2, (insn >> 16) & 0xff); set_program8 (vaddr + 1, (insn >> 8) & 0xff); set_program8 (vaddr, insn & 0xff); #else set_program8 (vaddr, (insn >> 24) & 0xff); set_program8 (vaddr + 1, (insn >> 16) & 0xff); set_program8 (vaddr + 2, (insn >> 8) & 0xff); set_program8 (vaddr + 3, insn & 0xff); #endif Your change is correct. Perhaps you can submit a unified diff? Also, the simmem_{read,write}{16,8} functions in peripheral/memory.c need to be patched to handle big endian correctly. There is testbench/mem_test, which you can use to verify that everything is ok with endianess. > I downloaded the tar ball of or1k and built binutils, gcc and gdb > for or32 successfully for SunOS sun4u sparc SUNW,Ultra-80. Another stupid question, is this a 32-bit or 64-bit processor? nog. _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc

or1ksim simulator question - endianess issue confirmed by Unknown on Oct 13, 2005			Not available!
Hi Gyvrgy, This is to follow up the big endian modification you recommended. I patched simmem_read16/8 and simmem_write16/8 in periphal/memory.c. Basically I use the address directly when WORDS_BIGENDIAN is set. I noticed that I have to revert the changes I made in addprogram function of cpu/common/parse.c. Because the set_program8 function uses the function pointer that eventually leads to simmem_write8. With this change, the basic tests and the mem_test are fine now. I still have a couple of other tests hang for some reason. For example the eth and uart tests hang. How do generate a unified diff? Do you think now it is the time? -Charles -----Original Message----- From: <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">openrisc-bounces at opencores.org</A> [mailto:<A HREF="http://www.opencores.org/mailman/listinfo/openrisc">openrisc-bounces at opencores.org</A>] On Behalf Of Charles Qi Sent: Thursday, October 06, 2005 10:41 PM To: <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">openrisc at opencores.org</A> Subject: RE: [openrisc] or1ksim simulator question - endianess issue confirmed Hi, I am not sure that if I made the change at the correct place. But by factor in the ENDIAN issue in the addprogram routine, my simulator works. void addprogram(oraddr_t address, uint32_t insn, int* breakpoint) { int vaddr = (!runtime.sim.filename) ? translate(address,breakpoint) : translate(freemem,breakpoint); /* We can't have set_program32 functions since it is not gauranteed that the * section we're loading is aligned on a 4-byte boundry / /ZQI patch/ #ifdef WORDS_BIGENDIAN set_program8 (vaddr + 3, (insn >> 24) & 0xff); set_program8 (vaddr + 2, (insn >> 16) & 0xff); set_program8 (vaddr + 1, (insn >> 8) & 0xff); set_program8 (vaddr, insn & 0xff); #else set_program8 (vaddr, (insn >> 24) & 0xff); set_program8 (vaddr + 1, (insn >> 16) & 0xff); set_program8 (vaddr + 2, (insn >> 8) & 0xff); set_program8 (vaddr + 3, insn & 0xff); #endif It might have something to do with how the elf files are generated. Thanks -Charles [q] -----Original Message----- From: <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">openrisc-bounces at opencores.org</A> [mailto:<A HREF="http://www.opencores.org/mailman/listinfo/openrisc">openrisc-bounces at opencores.org</A>]On Behalf Of Charles Qi Sent: Thursday, October 06, 2005 9:44 AM To: 'List about OpenRISC project' Subject: RE: [openrisc] or1ksim simulator question - built fine and doesn't run Hi nog, Thanks for looking into this. It is a big-endian machine. Actually that might be the problem. Because I tried to run one instruction with the simulator and it generates an invalid instruction exception. (sim) run 1 00000104: : e81fe2d7 <invalid> (executed) [cycle 20, #2] 00018f40: : 00000000 l.j 0x0 (next insn) I looked at the objdump of dhry and it shows f0000104: d7 e2 1f e8 l.sw 0xffffffe8(r2),r3 Notice that d7e21fe8 is completely reversed. The fact that I don't have any exception handler causes all the subsequent instructions to be l.j 0x0. How do you recommend fix it? -Charles [q]> I downloaded the tar ball of or1k and built binutils, gcc and gdb > for or32 successfully for SunOS sun4u sparc SUNW,Ultra-80.[/q] Is this a big endian processor by chance? [q]> When I actually try to run the simulation like [q] >or32-uclinux-sim -i testbench/dhry[/q] All device instantiation (like memory, uart, ethernet, etc.) are done in a configuration file. For a detailed description of its format see sim.cfg in the top level simulator directory. Most of the testbenches use the testbench/default.cfg (which is a little different to the default config file). Other tests have their own config files, like the mmu uses testbench/mmu.cfg. You can tell the sim which config file to use with the `-f' switch. Thus your example, should, correctly, have been or32-uclinux-sim -i -f testbench/default.cfg testbench/dhry [q]> > I am wondering if there is a HowTo that describes how to use the > simulator.[/q] Unfourtonatly there is none. nog. _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A> _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A> [/q] _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A> Hi Gyvrgy, This is to follow up the big endian modification you recommended. I patched simmem_read16/8 and simmem_write16/8 in periphal/memory.c. Basically I use the address directly when WORDS_BIGENDIAN is set. I noticed that I have to revert the changes I made in addprogram function of cpu/common/parse.c. Because the set_program8 function uses the function pointer that eventually leads to simmem_write8. With this change, the basic tests and the mem_test are fine now. I still have a couple of other tests hang for some reason. For example the eth and uart tests hang. How do generate a unified diff? Do you think now it is the time? -Charles -----Original Message----- From: openrisc-bounces at opencores.org [mailto:openrisc-bounces at opencores.org] On Behalf Of Charles Qi Sent: Thursday, October 06, 2005 10:41 PM To: openrisc at opencores.org Subject: RE: [openrisc] or1ksim simulator question - endianess issue confirmed Hi, I am not sure that if I made the change at the correct place. But by factor in the ENDIAN issue in the addprogram routine, my simulator works. void addprogram(oraddr_t address, uint32_t insn, int breakpoint) { int vaddr = (!runtime.sim.filename) ? translate(address,breakpoint) : translate(freemem,breakpoint); /* We can't have set_program32 functions since it is not gauranteed that the * section we're loading is aligned on a 4-byte boundry / /ZQI patch*/ #ifdef WORDS_BIGENDIAN set_program8 (vaddr + 3, (insn >> 24) & 0xff); set_program8 (vaddr + 2, (insn >> 16) & 0xff); set_program8 (vaddr + 1, (insn >> 8) & 0xff); set_program8 (vaddr, insn & 0xff); #else set_program8 (vaddr, (insn >> 24) & 0xff); set_program8 (vaddr + 1, (insn >> 16) & 0xff); set_program8 (vaddr + 2, (insn >> 8) & 0xff); set_program8 (vaddr + 3, insn & 0xff); #endif It might have something to do with how the elf files are generated. Thanks -Charles -----Original Message----- From: openrisc-bounces at opencores.org [mailto:openrisc-bounces at opencores.org]On Behalf Of Charles Qi Sent: Thursday, October 06, 2005 9:44 AM To: 'List about OpenRISC project' Subject: RE: [openrisc] or1ksim simulator question - built fine and doesn't run Hi nog, Thanks for looking into this. It is a big-endian machine. Actually that might be the problem. Because I tried to run one instruction with the simulator and it generates an invalid instruction exception. (sim) run 1 00000104: : e81fe2d7 (executed) [cycle 20, #2] 00018f40: : 00000000 l.j 0x0 (next insn) I looked at the objdump of dhry and it shows f0000104: d7 e2 1f e8 l.sw 0xffffffe8(r2),r3 Notice that d7e21fe8 is completely reversed. The fact that I don't have any exception handler causes all the subsequent instructions to be l.j 0x0. How do you recommend fix it? -Charles > I downloaded the tar ball of or1k and built binutils, gcc and gdb > for or32 successfully for SunOS sun4u sparc SUNW,Ultra-80. Is this a big endian processor by chance? > When I actually try to run the simulation like >or32-uclinux-sim -i testbench/dhry All device instantiation (like memory, uart, ethernet, etc.) are done in a configuration file. For a detailed description of its format see sim.cfg in the top level simulator directory. Most of the testbenches use the testbench/default.cfg (which is a little different to the default config file). Other tests have their own config files, like the mmu uses testbench/mmu.cfg. You can tell the sim which config file to use with the `-f' switch. Thus your example, should, correctly, have been or32-uclinux-sim -i -f testbench/default.cfg testbench/dhry > > I am wondering if there is a HowTo that describes how to use the > simulator. Unfourtonatly there is none. nog. _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc

or1ksim simulator question - endianess issue confirmed by Unknown on Oct 13, 2005			Not available!
[q] With this change, the basic tests and the mem_test are fine now. I still have a couple of other tests hang for some reason. For example the eth and uart tests hang.[/q] If it is hanging while simulateing an instruction, turn on execution logging and the problem instruction should be the one after the last one in the log. If it is the peripheral simulation that's busted, pass `-d +eth' or `-d +uart' respectively to get debug output for that peripheral. [q] How do generate a unified diff? Do you think now it is the time?[/q] The more incremental (smaller) you can keep the patch the better, yes now would be a good time. If you are working from a cvs tree (one which has all the CVS/ dirs), you just do `cvs diff -u' in the root or1ksim dir and it outputs on stdout all changes that you made. If you aren't working from a cvs tree just run `diff -ur <dir to unmodified sources> .' And then send its output to the list for review and include a short changelog message. nog. With this change, the basic tests and the mem_test are fine now. I still have a couple of other tests hang for some reason. For example the eth and uart tests hang. If it is hanging while simulateing an instruction, turn on execution logging and the problem instruction should be the one after the last one in the log. If it is the peripheral simulation that's busted, pass `-d +eth' or `-d +uart' respectively to get debug output for that peripheral. How do generate a unified diff? Do you think now it is the time? The more incremental (smaller) you can keep the patch the better, yes now would be a good time. If you are working from a cvs tree (one which has all the CVS/ dirs), you just do `cvs diff -u' in the root or1ksim dir and it outputs on stdout all changes that you made. If you aren't working from a cvs tree just run `diff -ur .' And then send its output to the list for review and include a short changelog message. nog.

no use

no use

1/1

no use

no use

© copyright 1999-2026 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.