Wojciech A. Koszek | 28 Feb 10:41
Picon
Favicon

OpenCores-related internships?

Hi,

I wonder if we have any companies interested in accepting international
students who are willing to work with FPGA/Verilog and C programming for the
duration of the summer, 2009? If so, let us, young FPGA enthusiasts, know!
Private messages are accepted as well, of course!

I'm aware that this might be slight OT on this mailing list.

Thanks,

--

-- 
Wojciech A. Koszek
wkoszek <at> FreeBSD.org
http://people.freebsd.org/~wkoszek/
Fabien Marteau | 24 Feb 16:42
Favicon

Peripherals On Demand

Hello,

I'm a member of the ARMadeus development team, this company designs embedded
systems based on ARM processors (i.MX) and FPGA (Spartan) and it's proud to
announce the availability of its news card named apf27 (description can be
found here
:http://www.armadeus.com/english/products-processor_boards-apf27.html).

To ease FPGA usage for software developers, a GPL command line tool
(POD) has been written which can connect automatically severals
"virtual" components together by means of a Wishbone bus.

The specification of  POD can be found here:
http://www.armadeus.com/wiki/index.php?title=POD_specification
(from fpga wiki page : http://www.armadeus.com/wiki/index.php?title=Using_FPGA)

The main goal of POD is to permit FPGA-newbies to use fpga without writing any
VHDL (or verilog) code. The user can choose component he wants in a components
library and include it in his project.  POD will generate automatically the
"glue-files" to produce the FPGA configuration bitstream for the fpga (wishbone
intercon, top VHDL hierarchy,tcl script to automatize synthesis, pinout files,
...) and the drivers on the OS side (if component has drivers templates for the OS).

The principle of POD is to package HDL components in a directory together with
a component description file (XML).  Code/Drivers template can be added in to
automatize drivers generation for target operating system that will use
projects components.  Code/driver templates can be easily added

Currently few components are integrated in POD:

* bram: just for test, instanciate spartan ram
* button : manage a user button generating interrupts
* led : manage a simple led with a register
* simplegpio : a minimalistic input/output manager
* irq_mngr : this components manage interrupts from fpga to processor.

And some come from opencore:

* I2C master
* uart16550

POD is designed to be used with other platforms than the Armadeus ones.
Actually 3 platforms are supported:  2 ARM-Spartan architectures
(Armadeus APF9328 and APF27 boards) and one Atmega-Cyclone architecure
named UNIOC

POD is also designed to support other bus than Wishbone. Actually POD supports
two simples versions of the Wishbone bus: one version with a 16bits data bus
(iMX) and an other with a 8 bits data bus (Atmega)

The source code of POD is released in GPL and can be found on sourceforge
repository:
http://periphondemand.sourceforge.net/

It is theoretically usable on any operating system (written in Python)
but it has only been tested on a Linux/Debian distribution

A use case tutorial can be found on wiki, to explain the usage of POD:
http://www.armadeus.com/wiki/index.php?title=POD_Tutorial

If you are interested by this project feel free to register on sourceforge
mailing list :
https://lists.sourceforge.net/lists/listinfo/periphondemand-devel

Cheers
Fabien Marteau
fabien.marteau <at> armadeus.com

chris.reeg | 20 Feb 18:05
Picon

UART 16550 Addressing

Hello All,

I was wondering if anyone could explain a line in the 16550 code.  I'm
trying to do a simple test with this core but wasn't able to get it
working.  I know I can't simulate it because it uses the on-chip ram
but I can at least simulate the initialization of the core.  

In the wishbone interface file uart_wb, there is a line at the bottom
of the file that practically (at least how I'm reading it) destroys
the address value that is being passed into the core.  It takes the
top 3 bits and concats them with a value determined by the data select
lines.  This doesn't make any sense to me.  The data select lines
should be used to select which portion of the data lines should be
read or written, not to determine what register address to write to. 
The bottom two bits of the address are simply wiped out.

Can anyone offer any insight to this?

Thanks,
Chris
Jeremy Bennett | 19 Feb 23:44

Cycle accurate modeling ORPSoC with Verilator

I've just published a tutorial on creating fast cycle accurate SystemC
models using Verilator, using ORPSoC as an example.

        http://www.embecosm.com/download/ean6.html

Verilator is an open source tool, which generates C++ and SystemC cycle
accurate models automatically from Verilog RTL (see
www.veripool.org/wiki/verilator). The resulting models follow synthesis
semantics (2-state, zero delay) and are often considerably quicker than
event-driven simulation.

I've used the OpenRISC Reference System-on-Chip (SoC) with 2MB flash and
2MB SRAM as an example. An event driven simulation using Icarus Verilog
runs at about 1.4kHz on my PC, while the Verilator SystemC model runs at
130kHz.

That's quick enough to run useful firmware. I've also hooked the JTAG
ports up to GDB via RSP and used it to load and debug software.

The tutorial includes complete software examples:

        http://www.embecosm.com/download/esp5.html

Those examples will also be uploaded to OpenCores in the coming days.

The tutorial and example code are all free and open source under
Creative Commons and GPL licenses.

Feedback and comments welcome. I'm particularly interested in
comparative performance data from commercial simulators (NC, VCS,
ModelSim).

Cross-posted to OpenCores and OpenRISC mailing lists, because the
subject is of general interest, while the example is OpenRISC.

Jeremy

--

-- 
Tel:      +44 (1202) 416955
Cell:     +44 (7970) 676050
SkypeID: jeremybennett
Email:   jeremy.bennett <at> embecosm.com
Web:     www.embecosm.com

magnus.wedmark | 17 Feb 09:10
Picon

Re: Plasma/Xilinx problem

Thanks to both of you, Gunnar och Steve!

You are both correct, the P15 pin is one of the pins that are
different between 500E and the 1600E device in the 320-pin package. I
thought they were 100% pin-compatible..

Just as you said Steve I was mislead by the typos in the Microblaze
Starter Kit Manual papers (P16=>P15) but after looking either at the
Schematics and the white papers of the Spartan-3E yesterday night I
got it correct.

The first simple example of the Plasma, 'test.c' booted yesterday on
the 1600E! I managed to build the Plasma SOC with ISE 10.3 and to use
the precompiled Windows cross-compilation suite to build the test.c

I want to test both the DDR and the Ethernet functionality on my card
in the near future!

I noticed that the VGA-signals are being connected at the top level,
are there any demos of it being used? Simple text display, graphics?

Anyone tried booting it/loading programs from a SD-Card? That would be
most useful. A bootloader (located in BRAM) that preloads a firmware
or lists the files for the user to choose.. The simplest way would
probably be to use for example EFSL through SPI and connect some of
the I/O directly. 

Thank you Steve for sharing some excellent work you've done with Plasma!

Best Regards
Magnus

----- Original Message ----- 
From: rhoads at opencores.org<rhoads <at> o...> 
To: 
Date: Mon Feb 16 01:06:45 CET 2009 
Subject: [oc] Plasma/Xilinx problem 

> Magnus, 
> 
> Regarding your problem with running the Plasma CPU on the 
> Microblaze 
> Starter Kit with the Spartan-3E 1600E FPGA: 
> > ERROR Pack:1107 - Unable to combine the following symbols into 
> a 
> > single IOB component: BUF symbol "E_TX_EN_OBUF" 
> > (Output Signal = E_TX_EN) PAD symbol "E_TX_EN" 
> > (Pad Signal = E_TX_EN) 
> > physical site for a component of type IOB: Symbol 
> > "E_TX_EN" (LOC=P15 [Physical Site Type = IBUF]) 
> I found the Microblaze Starter Kit documentation at: 
> http://www.xilinx.com/support/documentation/ 
> spartan-3e_board_and_kit_documentation.htm 
> Which led me to: 
> http://www.xilinx.com/support/documentation/boards_and_kits/ 
> ug257.pdf 
> Looking at the schematic on page 145 it looks like the E_TX_EN 
> (Ethernet Transmit Enable) signal is on pin P16 instead of P15. It 
> looks 
> like IR14 is on pin P15. The documentation appears inconsistant 
> since 
> the rest of the documentation refers to E_TX_EN being on pin P15. 
> Thanks, 
> Steve Rhoads 
> (Plasma CPU developer) 
> 
> 
> 
nitylles | 15 Feb 21:34
Picon

Re: Re: I2C syntax error in Synopsys


----- Original Message ----- 
From: Richard Herveille<richard <at> h...> 
To: 
Date: Wed Sep 22 14:58:35 CEST 2004 
Subject: [oc] Re: I2C syntax error in Synopsys 

> I'll remove the '_'. 
> 
> Cheers, 
> Richard 
> 
>  _____ 
> From: attachment.htm 
> 
> I also encounter this problem , after remove the "_" . problem still
exist.
djd328 | 11 Feb 19:44
Picon
Favicon

Re: uClinux on Plasma

From: magnus.wedmark at gmail.com<magnus.wedmark <at> g...> 
> Why would you like to run ucLinux today? From what I''ve gathered 
> all Linux 2.6-based kernals can run full Linux even on MMU-less CPU's. 
> Maybe the ucLinux uses less memory if you are tight, but I think 
> that is also mainly a config question.. 
> /Magnus 

uClinux was merged in the Linux 2.6 series.
It's still uClinux if it's MMU-less, even if it's from the Mainline Linux tree.

Here's a more recent complete version for MIPS no mmu.
http://jacksonm80.googlepages.com/linuxonpsp.htm

Looks to me like the largest work is the Plasma COP0 implementation,
which is just minimal.  Most of it seems to live in a hack in the Register File.
Cleaning this up seems like a good first step, at the expense of some gates.
Other than that, most of the work is like any other (uC)linux port.
magnus.wedmark | 11 Feb 10:19
Picon

Plasma/Xilinx problem

Hello,

Has somebody tried building the Plasma Core as shipped in the latest
Xilinx ISE 10.3 environment? I own a Microblaze Starter Kit (a bigger
brother to the 3E-Starter Kit used in the example) which hosts a
Spartan-3E 1600E Device instead of the 500E located on the more common
3E-Starter Kit. The pin out is identical of both of these as far as I
know.

I'm trying to build a working Plasma-SOC using the standard 
I've done the following:
- Created a new project using Spartan-3E 1600E
- Included the necessary files (f.e. ram_xilinx for the BRAM instanse)
- Did some changes in the VHDL code (mentioned in comments) to make it
work with Xilinx primitives/ISE
- Changed the SD<A4> address line pin config in the UCF for the DDR
which seemed to be off for me. F4=>E4

Still it is hassling me about the following problem, why is that? It
don't understand the problem.. 

-snip-
ERROR Pack:1107 - Unable to combine the following symbols into a
single IOB component: BUF symbol "E_TX_EN_OBUF" (Output Signal =
E_TX_EN) PAD symbol "E_TX_EN" (Pad Signal = E_TX_EN) An IO component
of type IOB was chosen because the IO contains symbols and/or
properties consistent with output or bi-directional usage and contains
no other symbols or properties that require a more specific IO
component type. Each of the following constraints specifies an illegal
physical site for a component of type IOB: Symbol "E_TX_EN" (LOC=P15
[Physical Site Type = IBUF]) The component type is determined by the
types of logic and the properties and configuration of the logic it
contains. Please double check that the types of logic elements and all
of their relevant properties and configuration options are compatible
with the physical site type of the constraint. Please correct the
constraints accordingly.
-snip-

Anybody care to comment? It sure would be nice to see the Plasma boot
on my card. Thanks in advance!

Best Regards
Magnus
jhonson.zhu | 4 Feb 15:29
Picon

New version of VHCG released

hi cores,

New version of VHCG is released. I added Direct Traceback Option like 
Xilinx Viterbi Compiler. And Self Test Module for it.
Please try it. Here is the link:
http://www.opencores.org/projects.cgi/web/vhcg/overview
Please email to me <jhonson.zhu <at> gmail.com>, if you have questions.

Thanks
Shengzhu
Texblues | 1 Feb 19:38
Picon
Favicon
Gravatar

uClinux on Plasma

Hi

CPU Plasma is fully MIPS architecture. Now I wonder or I can run on Plasma  
CPU uClinux. Anyone try this?
Rick Collins | 30 Jan 16:57
Favicon

Re: GPL License - again

At 10:24 AM 1/29/2009, you wrote:
>I support Victor Lopez choosing whatever terms and conditions he
>wants, for the things he produces.
>
> >> From: Rick Collins
>...
> >> Does anyone know of court cases relating to copyright of IP as
> >> expressed in hardware?
>...
>
>I'm not a lawyer, but I have heard of a few cases involving copying
>chip hardware:
>
>* "Apple Computer, Inc. v. Franklin Computer Corp." (1983) case

This case only relates to protection of software embodied in a 
computer ROM, not IP describing the hardware itself.

>* "Intel Corp. v. Advanced Micro Devices, Inc. 1990". In 1990, Intel
>brought a copyright infringement action alleging illegal use of its
>287 microcode.

I am familiar with this case.  As you say, it involved copyright as 
applied to microcode, although I didn't think it was limited to the 
287 code, but rather applied to the 486 code.  Maybe there was more 
than one case between these two.  In the 486 case, it was ruled that 
AMD could not literally copy the 486 microcode, but rather had to use 
a "'cleanroom" approach to reproduce the code in as much detail as 
could be specified in a document by a team of engineers reverse 
engineering the code and a team of engineers creating the new 
code.  This lead to AMD producing a functionally equivalent, but not 
copied, version of the 486 microcode.  Since they never had any of 
the Intel IP, this case is not relevant to the question of copyright.

>* "The first chip-layout copying case", IEEE Micro, Aug 1991, which
>describes "Brooktree Corp. v. Advanced Micro Devices, Inc. 1990" in
>detail, has illustrations of the SRAM memory cell in question.

This does not appear to be a copyright case, "Brooktree Corporation 
brought suit against Advanced Micro Devices, Inc. (herein AMD) for 
patent infringement"

>I've seen other things that seem to imply even more cases involving
>copying chip hardware and copyright (or something similar to
>copyright):
>
>* chip art. Have you seen the Silicon Zoo? Supposedly, some of that
>art was intended to prove that a copied chip was a direct copyright
>violation, and not innocent convergent design.
>* I've also been told that "The exclusive rights in a mask work are
>somewhat like those of copyright ... rights in semiconductor mask
>works last 10 years", from the Semiconductor Chip Protection Act of
>1984

Yes, if a chip is copied as in photographically copied, that would be 
a copyright violation.  But we are talking about using the source to 
produce an implementation embodied in a chip.  Or in more specific 
terms, will the GPL applied to HDL prevent its use in a proprietary product?

The GPL covers only specific acts.  "Activities other than copying, 
distribution and modification are not
covered by this License" (translation is specifically included in 
modification).  The question is whether producing a chip from an HDL 
program is the same as compiling software to machine code; is 
creating chip masks or FPGA bitstreams from IP considered 
"modification" or "translation" of the original IP?

There are a lot of interesting analogies that could be made to this 
situation.  I wonder how much difference in application would come 
from the use of a program, such as a synthesis tool, to produce the 
end result.  If I obtain plans to a copyrighted house design and 
construct my own house from that, I would not expect that to be a 
violation of that copyright.  I would not consider that to be 
"copying" "distributing" or "translating" the plans.  IF there was a 
standard that told you exactly how to produce a doorway from the 
symbol on the plan and how to make the walls and floors and roof from 
the dimensions on that page, maybe that could be considered 
"translating".  To me, the difference is how much this "construction" 
requires intelligent thought be used to produce the result vs. how 
much of it is obvious from the plans.

In the case of expression of an HDL program, I can see where much of 
the HDL clearly specifies *what* is being produced.  Normally the 
functionality of logic is clear even though the actual implementation 
in LUTs or gates is not specified.  The functionality of registers is 
clear even if it does not specify whether those registers are single 
FFs in several blocks or a single LUT used as a shift 
register.  Often even the intent of using a block RAM vs an array of 
FFs is clear and so a block RAM could be said to be "specified" in 
the original work.  So I would have to say that synthesizing a design 
from an HDL description would be considered "translating" and so 
covered under the GPL even if it is decided to *not* be considered a 
violation of copyright.

However, the other side of the coin is the amount of additional 
effort is embodied in producing the resulting work.  Any synthesis is 
followed by the layout process.  The objects must be positioned on 
the device and they much be interconnected by routing.  I believe it 
has already been ruled that a "circuit" may be copyrighted in the 
form of a schematic, but the use of the inherent circuit in physical 
form is can not be protected by copyright.

But the GPL does not depend on copyright.  It is a license.  So in 
the end, I believe the question comes down to whether the act of 
placement and routing of the objects specified in the original HDL IP 
is considered "modification" or "translation" of the original IP or 
if it would be outside of that definition.  Since it is a level of 
specification that goes beyond the original IP, I believe it is *not* 
"modification" as specified (which specifically includes translation) 
in the GPL and so hardware that is produced from GPL'd HDL IP is not 
covered in the same way that machine code in a ROM would be.

Rick

>.. _Apple Computer, Inc. v. Franklin Computer Corp.
>http://en.wikipedia.org/wiki/Apple_Computer,_Inc._v._Franklin_Computer_Corp.
>.. _Franklin Computer Corp.
>http://en.wikipedia.org/wiki/Franklin_Computer_Corporation
>.. _Intel v. AMD
>http://en.wikipedia.org/wiki/Advanced_Micro_Devices#Litigation_with_Intel
>.. _first chip-layout copying case
>http://docs.law.gwu.edu/facweb/claw/BrooktAMD.pdf
>
>.. _chip art http://en.wikipedia.org/wiki/Chip_art
>.. _Silicon Zoo http://micro.magnet.fsu.edu/creatures/index.html
>.. _"Steal The Best" http://micro.magnet.fsu.edu/creatures/pages/russians.html
>.. _mask work http://en.wikipedia.org/wiki/Mask_work
>.. _Semiconductor Chip Protection Act of 1984
>http://en.wikipedia.org/wiki/Semiconductor_Chip_Protection_Act_of_1984
>
>--
>David Cary
>918.81.2279
>http://carybros.com/
>http://en.wikibooks.org/wiki/Microprocessor_Design
>_______________________________________________
>http://www.opencores.org/mailman/listinfo/cores


Gmane