Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 58925

Article: 58925
Subject: More VHDL issues..
From: rickman <spamgoeshere4@yahoo.com>
Date: Mon, 04 Aug 2003 12:58:45 -0400
Links: << >>  << T >>  << A >>
I added a variable to calculate a time for a wait statement in a
testbench and am not getting this error from ModelSim...

  Signal arm_command is read by the VITAL process but is NOT in the
sensitivity list


This is the line of code producing the error...

  WaitTime := (ARM_command.RelTime - (now - CurrentTime));

I follow this up with a check for negative values before using in the
wait.  ARM_command is a signal and WaitTime and CurrentTime are
variables.  And of course all these objects are of type time.  This same
calculation done directly in the wait statement gives no error.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 58926
Subject: Re: opencores.org - Question on project licensing?
From: russelmann@hotmail.com (Rudolf Usselmann)
Date: 4 Aug 2003 10:04:43 -0700
Links: << >>  << T >>  << A >>
"Pacbell User" <dont_reply@dont_reply.com> wrote in message news:<sSgXa.472$gC7.418@newssvr23.news.prodigy.com>...
> I would like to contribute a multi-cycle (slow, but area-compact)
> (Hehe, someone else already released a pipelined integer-divider,
> to the opencores.org repository.  Gence I'm marketing my divider as
> 'compact'!)
> I am reading through the FAQ, and one part has me a bit confused...
> 
> ===
> 
> The 'licensing' portion -- I understand that the 'GPL' license
> is fairly restrictive in that it forces derivative works to be
> distributed in documented *AND* modifiable form.
> 
> My goal is to let *anyone* use my integer-divider as they see
> fit.  If they want to use it in a closed commercial project, that's
> fine.  It seems like a GPL-release cannot be used in a closed
> project, is that correct?
> 
> So under which license should I release my divider? LGPL, BSD, etc.?!?


Look at some other IP cores (perhaps some of mine) at
OpenCores. I faced the same problem that you are facing,
I wanted to protect myself but not limit the usage of
any of my IP cores. So I created my own "license". It's
on top of each of my files ...

Best Regards,
rudi               
--------------------------------------------------------
www.asics.ws  --- Solutions for your ASIC/FPGA needs ---
----------------- FPGAs * Full Custom ICs * IP Cores ---
FREE IP Cores --> http://www.asics.ws/ <-- FREE IP Cores

Article: 58927
Subject: Re: opencores.org - Question on project licensing?
From: Jon Masters <jonathan@jonmasters.org>
Date: Mon, 04 Aug 2003 18:09:15 +0100
Links: << >>  << T >>  << A >>
Pacbell User wrote:

> The 'licensing' portion -- I understand that the 'GPL' license
> is fairly restrictive in that it forces derivative works to be
> distributed in documented *AND* modifiable form.

LGPL will not really help you here and I am not really sure how you 
would apply it to a hardware design in any case. Can you LGPL license 
hardware designs and treat the situation is if you were linking against 
a library thus being ok with binary distribution? Does that really work?

I personally prefer the GPL over most other licenses however in this 
case either having no license or a BSD style one will probably suffice.

Jon.


Article: 58928
Subject: Re: Design fits XC9536 but not XC9536XL
From: arthuryang42spam@yahoo.com (Arthur)
Date: 4 Aug 2003 10:09:20 -0700
Links: << >>  << T >>  << A >>
Your design should fit going from the 9500 to the 9500xl. The 9500xl
actually has more function block fanin (36 to 54!) so I would think
that there should be no fitting issues. The only architectural
features lost are macrocell feedback and wire-anding in the AIM. The
loss of macrocell feedback should be made up for by the additional FB
inputs. The loss of wire-anding would cause your PTerm requirements to
increase. Perhaps if you were near the maximum utilization for this it
would not fit.

You may want to try contacting the Xilinx hotline. They are willing to
try fitting close designs.

Arthur

atali@cygrp.com (Aare Tali) wrote in message news:<a8b3964d.0308020956.1e3b61be@posting.google.com>...
> I hope Google won't eat the first reply, so here's an addition to it,
> some parts of fitter report are below:
> 
> news@rtrussell.co.uk wrote in message news:<bgdmcf$73u$1@nntp0.reith.bbc.co.uk>...
> > I have a design (admittedly making heavy use of the device resources)
> > which successfully fits into an XC9536 but not an XC9536XL.  This is
> > something I hadn't anticipated when migrating to the newer part.  Is
> > this to be expected, and is it likely that by tweaking any fitter
> > options (or otherwise) I will be able to get the design to fit ?
> > 
> > I am using Xilinx Foundation F4.2i, Build 3.1.196.
> > 
> > Richard.
> > http://www.rtrussell.co.uk/
> 
>  
> cpldfit:  version E.33                              Xilinx Inc.
>                                   Fitter Report
> Design Name: iw                                  Date:  4- 1-2003, 
> 4:17AM
> Device Used: XC95144XL-5-TQ144
> Fitting Status: Successful
> 
> ****************************  Resource Summary 
> ****************************
> 
> Macrocells     Product Terms    Registers      Pins           Function
> Block
> Used           Used             Used           Used           Inputs
> Used
> 143/144 ( 99%) 558 /720  ( 77%) 100/144 ( 69%) 111/117 ( 94%) 415/432
> ( 96%)
> 
> PIN RESOURCES:
> 
> Signal Type    Required     Mapped  |  Pin Type            Used  
> Remaining
> ------------------------------------|---------------------------------------
> Input         :   58          58    |  I/O              :   104       
> 5
> Output        :   44          44    |  GCK/IO           :     2       
> 1
> Bidirectional :    8           8    |  GTS/IO           :     4       
> 0
> GCK           :    1           1    |  GSR/IO           :     1       
> 0
> GTS           :    0           0    |
> GSR           :    0           0    |
>                  ----        ----
>         Total    111         111
> 
> *********************Function Block Resource
> Summary***********************
> Function    # of        FB Inputs   Signals     Total       O/IO     
> IO
> Block       Macrocells  Used        Used        Pt Used     Req      
> Avail
> FB1          18          53          53           67        12/0      
> 15
> FB2          18          53          53           57         7/0      
> 15
> FB3          18          51          51           87        14/0      
> 15
> FB4          18          51          51           71         0/1      
> 15
> FB5          18          52          52           83         8/0      
> 14
> FB6          18          52          52           72         1/7      
> 13
> FB7          18          51          51           66         0/0      
> 15
> FB8          17          52          52           55         2/0      
> 15
>             ----                                -----       -----    
> -----
>             143                                  558        44/8     
> 117
> 
> So, in dense design you can't rely on Xilinx tools only, I was always
> 1-2 cells over 144 when I was playing with options, so I had to
> constrain things myself...

Article: 58929
Subject: Re: 5 volt tolerant Xilinx parts
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Mon, 4 Aug 2003 17:11:27 +0000 (UTC)
Links: << >>  << T >>  << A >>
Austin Lesea <Austin.Lesea@xilinx.com> wrote:
...

: If you havce 90nm/.35u (no reason why it can't be done), you lose all your
: speed and area by having to drive the huge .35u transistors (makes for a
: more expensive die).

Austin,

just for interest, is there any document showing the schematics of such a 
mixed voltage output stage? I think driving the PMOS of the output stage is
quite tricky,  without sacrificing to much current.

Bye
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 58930
Subject: Re: 5 volt tolerant Xilinx parts
From: "B. Joshua Rosen" <bjrosen@polybus.com>
Date: Mon, 04 Aug 2003 15:04:31 -0400
Links: << >>  << T >>  << A >>
On Mon, 04 Aug 2003 09:46:48 -0700, Austin Lesea wrote:

> Rick,
> 
> It has to do with the foundires.
> 
> What do you offer as your lowest cost standard CMOS process?
> 
> .18/.35 was really popular (and still is).
> 
> .15/.35 was the half-step between .18 and .13.
> 
> .13/.25 is the dominat process right now (3.3V is a tough push, and has to
> be done carefully, and 5V is definitely gone)
> 
> 90nm/.25u is what we are in for Spartan 3, so there has to be a reason
> (like all those three letter companies that offer standard CMOS
> processes....)
> 
> If you havce 90nm/.35u (no reason why it can't be done), you lose all your
> speed and area by having to drive the huge .35u transistors (makes for a
> more expensive die).

Are you saying that you lose all of the speed and area over the whole die
or just for the IO section? If it's just the IO that would be OK in a part
like this. A part aimed at the 5V interface market doesn't need fast IOs
because the clock rates in that world are low. It does need the logic and
RAM density of a modern part, if it wasn't any denser than an old .18u
part then you might as well stick with the older part or live with
external level shifting transceivers.



Article: 58931
Subject: how to protect own IP in Xilinx ISE
From: Guenter Wolpert <guenter.wolpert@t-online.de>
Date: 04 Aug 2003 21:10:19 +0200
Links: << >>  << T >>  << A >>
Hello,

Is there a way to put a ready developed VHDL code into binary form,
so that other can use, but not read it?

Of course there is such a way, because the IP vendors live from that :-).

Does anyone know how to do this with the Xilinx ISE 5.x environment?

thanks in advance for any help.

Guenter (guenter.wolpert@t-online.de)




Article: 58932
Subject: Re: reconfiguration VirtexE via JTAG (full or partial)
From: Chen Wei Tseng <chenwei.tseng@xilinx.com>
Date: Mon, 04 Aug 2003 13:13:52 -0600
Links: << >>  << T >>  << A >>
Sergey,

The JSHUTDOWN command will do just fine. If your design has dll and/or 
ram, you may want to make sure you reset them.

You can automate the shutdown sequence with the XSVF player. Generate an 
SVF file with iMPACT or by hand, then convert the SVF fiel to XSVF file 
and play the XSVF file with XSVF.

Please take a look at XAPP058 for the XSVF player and converter and 
XAPP503 for detailed format on SVF.

Regards, Wei

Serg_Y wrote:
> Does it mean that figure 6. in xapp139 (Device configuration flow
> diagramm) has error? The "Reconfigure path" trough "Shundown sequence"
> is available or not?
> 
> under "shutdown sequence" i mean the process described on p14 XAPP139
> 
> [ from XAPP139
> 1. Load the CFG_IN instruction into the JTAG instruction register.
> Next, go to the SHIFT-DR
> ....
> COR (Configuration Option Register) with the SHUTDOWN bit = 1
> ....
> ]
> 
> the described process does not need access to PROG
> 
> --------------------
> 
> Thanks.
> Sergey.


Article: 58933
Subject: Re: Gates Counting?
From: Jon Elson <jmelson@artsci.wustl.edu>
Date: Mon, 04 Aug 2003 14:27:54 -0500
Links: << >>  << T >>  << A >>


Pankaj Rodey wrote:

> I have a querry regarding CPLD, we are using. It is XC9536XL and 
> XC9572TQ100 Xilinx CPLDs.
> I tried to develop a simple divide by two scheme, with a T flip flop, 
> with T pin tied high and clock given to flip flop through one of the 
> global clock I/O pins of CPLD. It is expected to get pulses of half 
> the frequency at Q output of the flip flop, with Q output toggling at 
> every positive edge of clock. However, I get some pulses of 
> continually varying frequency at the output pin.
> The devices I used are, XILINX WEBPACK ISE 4.2 as HDL editor, Impact 
> tool for program download.
> Kindly guide me as to the possible sources this ambiguity. 

Why not try a D flip-flop with the not-Q output connected back to the D 
input.

Jon


Article: 58934
Subject: Re: 5 volt tolerant Xilinx parts
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Mon, 04 Aug 2003 13:14:31 -0700
Links: << >>  << T >>  << A >>
Uwe,

Circuits to do this are considered proprietary.

I could do a search on google for level shifters, but you can, too.

Austin

Uwe Bonnes wrote:

> Austin Lesea <Austin.Lesea@xilinx.com> wrote:
> ...
>
> : If you havce 90nm/.35u (no reason why it can't be done), you lose all your
> : speed and area by having to drive the huge .35u transistors (makes for a
> : more expensive die).
>
> Austin,
>
> just for interest, is there any document showing the schematics of such a
> mixed voltage output stage? I think driving the PMOS of the output stage is
> quite tricky,  without sacrificing to much current.
>
> Bye
> --
> Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------


Article: 58935
Subject: Re: 5 volt tolerant Xilinx parts
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Mon, 04 Aug 2003 13:16:48 -0700
Links: << >>  << T >>  << A >>
This is left as an exercise for those who already know how to design these
circuits,

If you don't, then it is not my place to instruct.

Austin

"B. Joshua Rosen" wrote:

> On Mon, 04 Aug 2003 09:46:48 -0700, Austin Lesea wrote:
>
> > Rick,
> >
> > It has to do with the foundires.
> >
> > What do you offer as your lowest cost standard CMOS process?
> >
> > .18/.35 was really popular (and still is).
> >
> > .15/.35 was the half-step between .18 and .13.
> >
> > .13/.25 is the dominat process right now (3.3V is a tough push, and has to
> > be done carefully, and 5V is definitely gone)
> >
> > 90nm/.25u is what we are in for Spartan 3, so there has to be a reason
> > (like all those three letter companies that offer standard CMOS
> > processes....)
> >
> > If you havce 90nm/.35u (no reason why it can't be done), you lose all your
> > speed and area by having to drive the huge .35u transistors (makes for a
> > more expensive die).
>
> Are you saying that you lose all of the speed and area over the whole die
> or just for the IO section? If it's just the IO that would be OK in a part
> like this. A part aimed at the 5V interface market doesn't need fast IOs
> because the clock rates in that world are low. It does need the logic and
> RAM density of a modern part, if it wasn't any denser than an old .18u
> part then you might as well stick with the older part or live with
> external level shifting transceivers.


Article: 58936
Subject: Re: Tiny TCP/IP stack and tiny MAC controller on FPGA for direct download to S(D)RAM memory
From: wv9557@yahoo.com (Will)
Date: 4 Aug 2003 14:03:23 -0700
Links: << >>  << T >>  << A >>
If you ever looked at a software stack, you will find that one of the
most CPU intensive operation during the handling of an IP packet is
the checksum calculation. Most software stacks will do this in assembly.
Now if you could do this in hardware, this should save the host CPU
a bunch of time. 
The other thing is that networking switches employ hardware lookup
(using CAM) to decide which port an incoming network frame should go out.
A router could probably use a similar scheme to route a packet,
avoiding a routing table in software(software means slow.)
If you are paranoid about speed, then you could have your hardware 
forming the ACK packets, while handling the incoming packet (to ack)
Note that you can create an ACK packet as soon as the sequence number
of a TCP segment is seen - you dont have to wait to see the whole segment (as 
a software implementation)
All the optimizations, short cuts, parallelizations that you could think
of in a hardware implemenation should be fun, and all that.
 However, from a pratical point of
view, when you are dowloading files from a computer halfway across the
world, you don't really need a very fast stack, because the download site
doesn't care if you can ack a TCP segment in 1 or 10 seconds. Not to
mention the fact that your packet will traverse 10 routers to get there.
You do your best to get the packet as fast as you could out of your box,
but it's the networking equipment you have no control of that will slow you
down.


erik.coenders@philips.com (Erik Coenders) wrote in message news:<f5fc2c9a.0307310717.4d340e4a@posting.google.com>...
> Hi,
> 
> As a study for a project I need to investigate the possibility of
> implementing a tiny TCP/IP stack and tiny MAC controller on FPGA. This
> stack is capable to transfer some data packets directly into S(D)RAM
> without help of the microcontroller. Thus a simple communication via
> Ethernet from the desktop PC is required for download/upload to/from
> the memory.
> 
> The FPGA board is attached to an Ethernet PHY device such as DP83847A.
> In this case a MAC controller was implemented in FPGA but the FPGA
> utilitization is too high. There is less room available for other
> blocks. My intention is to build a small TCP/IP stack and MAC blocks
> in the FPGA and the transaction between FPGA/Ethernet PHY and the
> desktop PC has to kept as simple as possible. Thus no heavy/extensive
> protocol is needed.
> 
> The questions raised are:
> 1. What is the minimum TCP/IP function set required to do simple file
> transfer and etc.?
> 2. Is it possible to perform all tasks only in FPGA without help of
> the microprocessor?
> 3. Are there any resources (VHDL code and C program on PC) available
> on this topic?
> 
> I will welcome all comments and suggestions. please feel free to write
> us at erik.coenders@philips.com Thank you all.

Article: 58937
Subject: Re: Xuart Lite Linux driver
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Tue, 05 Aug 2003 08:06:21 +1000
Links: << >>  << T >>  << A >>
Jon Masters wrote:
> Hi,
> 
> Can someone tell me if there is a Xuart Lite driver for Linux already 
> and where I might find the patches before I continue with writing one?
> 
Hi Jon,

I got my UARTlite driver for uClinux working just yesterday, still a 
couple of bugs but expect to iron them out today.  You are welcome to 
try it in PPC linux if you wish - just send me an email or check it out 
of the uClinux CVS tree - it should be in there by now.  In principle it 
should drop straight into Linux.

Cheers,

John
--
Microblaze uClinux web site
http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux



Article: 58938
Subject: Re: LCD and step-up DC-DC converter.
From: symon_brewer@hotmail.com (Symon)
Date: 4 Aug 2003 15:33:13 -0700
Links: << >>  << T >>  << A >>
Laurent,
      You could build a charge pump with 2 diodes and 2 caps driven
with a square wave from your 3.3V FPGA IO. Well, you wanted cheap!
           HTH, Syms.


Amontec Team <laurent.gauch@www.DELALLCAPSamontec.com> wrote in message news:<3f2e6c8c$1@news.vsnet.ch>...
> Hi,
> 
> I have to connect a LCD-I2C to my FPGA.
> My LCD can be supplied only with 5V, and I have only a 3.3V.
> 
> Do you know a low cost step-up dc-dc converter solution.
> 
> I only need 2 mA as output current.
> 
> Regards,
> Laurent

Article: 58939
Subject: Re: 5 volt tolerant Xilinx parts
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Mon, 4 Aug 2003 22:47:09 +0000 (UTC)
Links: << >>  << T >>  << A >>
Austin Lesea <Austin.Lesea@xilinx.com> wrote:
: Uwe,

: Circuits to do this are considered proprietary.

: I could do a search on google for level shifters, but you can, too.

The basic concept is clear for me. An Open Collector/OpenDrain as switch and
a pullup resistor ( in the discret case) or a depletion NMOS( in the
integrated case) as load. But to get that at speed at low current ...

Bye 

-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 58940
Subject: [ANN] uClinux Microblaze Update
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Tue, 05 Aug 2003 09:07:07 +1000
Links: << >>  << T >>  << A >>
Hi everyone,

A few months ago I posted announcing the existence of the porting effort 
to get uClinux on the Microblaze soft-core processor.  Things have come 
a long way since then, so here's an update on the project status.  More 
information can be found on the project web site:

http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux

News:

- Core kernel port is complete.

- A TTY/console driver for the UARTLite is done and mostly functional.

- The kernel boots to an interactive shell.

- The /proc filesys can be mounted and queried.

- Busybox utils build but are not tested yet.

- Xilinx has mentioned the uClinux port in an official publication 
(http://www.xilinx.com/xapp/xapp477.pdf).

- The project website has been revised.

Up-to-date sources are hosted on the uClinux anonymous CVS - cvs.uclinux.org

Regards,

John
-- 
Dr John Williams, Research Fellow,
Reconfigurable Computing, School of ITEE
University of Queensland, Brisbane, Australia
Ph : (07) 3365 8305


Article: 58941
Subject: Patent granted for "system on a chip" framework?
From: y_p_w@hotmail.com (y_p_w)
Date: 4 Aug 2003 16:24:15 -0700
Links: << >>  << T >>  << A >>
The URL would be too long.  It's patent 6,601,126, and
is available at <http://patft.uspto.gov/netahtml/srchnum.htm>

There was an EE Times (and other CMP websites) article about
this story.

<http://www.eet.com/semi/news/OEG20030801S0043>

This sounds fishy to me.  I've personally worked on SoC designs
using only uni-directional busses with various asynchronous
peripherals - well before the time this patent was filed.  I'd
like to see PalmChip try to enforce this patent.  The EET article
also mentions that FPGAs have been using this kind of technology
for a while.

Here are some of the "claims" of the patent:

"1. An on-chip interconnection system, comprising: 

a single semiconductor integrated circuit (IC); 

a plurality of uni-directional buses disposed in the IC; 

a peripheral-bus (p-bus) included in the plurality of uni-directional
buses and that uses a simple non-pipelined protocol and supports both
synchronous and asynchronous slave peripherals;

a p-bus controller connected to the p-bus and constituting an only
bus-master, and including a centralized address decoder for generating
a dedicated peripheral select signal, and providing for a connection
to synchronous and asynchronous slave peripherals, and further
providing for an input/output (I/O) backplane that allows a processor
to configure and control any of its slave peripherals; and

an m-bus included in the plurality of uni-directional buses, and for
providing a direct memory access (DMA) connection from any said slave
peripherals to a main memory and permits peripherals to transfer data
directly without processor intervention.

2. The on-chip interconnection system of claim 1, wherein, there are
included no tri-stated-buses, and no bi-directional buses.

3. The on-chip interconnection system of claim 1, wherein, each signal
has only a single buffer driver.

4. The on-chip interconnection system of claim 1, wherein, any
broadcast signals are re-driven by simple buffers with no extra
control logic."

Article: 58942
Subject: Re: Xuart Lite Linux driver
From: Jon Masters <jonathan@jonmasters.org>
Date: Tue, 05 Aug 2003 00:34:28 +0100
Links: << >>  << T >>  << A >>
John Williams wrote:

> I got my UARTlite driver for uClinux working just yesterday

Scary stuff indeed John!

I was going through the serial driver code recently and realised this is 
not going to be a trivial patch because there is no standard support for 
describing odd register offsets like with the XuartLite in serial.c. 
Certainly I will try your driver and submit any patches and so forth.

> still a couple of bugs but expect to iron them out today.

I will check out your source from work and take a look tomorrow but 
please do keep me posted of any and all bugs so I can help you out.

> You are welcome to try it in PPC linux if you wish

I most certainly do. Should save me some time since I have a kernel 
booting now on the Insight board and falling over after it tries to 
flush the ring buffer to a non-existent serial console.
I am actually really pleased because prior to this there were a whole 
host of memory management issues which would not go away and still there 
are spurious and unexplaned Machine Checks that e.g. NetBSD just ignore.

> In principle it should drop straight into Linux.

If not I am certainly not bothered in fixing that since you are saving 
me another day of grind before being able to use this system!
I was looking at the Microblaze stuff earlier thinking someone must have 
already solved this problem and avoided buying the 16550 for Linux.

The other implementations I have seen rely on the 16550 which is all 
very well but in this case the plan is to use the funky Xuartlite.
Once you get past the alignment issues it is actually ok talking to it - 
I have low level non-interrupt drivers for ppc_md and so forth but need 
a full interrupt driven driver via the xintc controller which there is 
already working in our hardware design...

> http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux

Is this a University related project perchance?
Having just graduated from my second University I am finally looking at 
PhDs in embedded real time systems - the hope is to tie my commercial 
and part time study together with some of this tech.

Jon.


Article: 58943
Subject: Re: how to protect own IP in Xilinx ISE
From: "Jim Wu" <jimwu88NOOOOSPAM@yahoo.com>
Date: Mon, 04 Aug 2003 23:50:29 GMT
Links: << >>  << T >>  << A >>
For Xilinx FPGAs, you can distrubute IP cores in Xilinx binary database
format (.ngo files). Take a look at 'edif2ngd' command.

Jim Wu
jimwu88NOOOOOSPAM@yahoo.com

Guenter Wolpert <guenter.wolpert@t-online.de> wrote in message
news:4r0xgrxg.fsf@linux.local...
> Hello,
>
> Is there a way to put a ready developed VHDL code into binary form,
> so that other can use, but not read it?
>
> Of course there is such a way, because the IP vendors live from that :-).
>
> Does anyone know how to do this with the Xilinx ISE 5.x environment?
>
> thanks in advance for any help.
>
> Guenter (guenter.wolpert@t-online.de)
>
>
>



Article: 58944
Subject: Re: Xuart Lite Linux driver
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Tue, 05 Aug 2003 09:57:22 +1000
Links: << >>  << T >>  << A >>
Hi Jon,

Jon Masters wrote:

> I was going through the serial driver code recently and realised this is 
> not going to be a trivial patch because there is no standard support for 
> describing odd register offsets like with the XuartLite in serial.c. 
> Certainly I will try your driver and submit any patches and so forth.

Yeah I had a few tough moments figuring out the alignment and dealing 
with pointer aliasing and stuff - seems to be mostly figured out now.

The uartlite is a funny thing, on the surface it looks like a fully 
featured uart, but when I delved a bit deeper there are some 
idiosyncracies that make it just that bit more tricky - like the 
interrupt generation, for example.

> I most certainly do. Should save me some time since I have a kernel 
> booting now on the Insight board and falling over after it tries to 
> flush the ring buffer to a non-existent serial console.
> I am actually really pleased because prior to this there were a whole 
> host of memory management issues which would not go away and still there 
> are spurious and unexplaned Machine Checks that e.g. NetBSD just ignore.

OK cool.  What is the status of V2Pro/PPC linux these days from a user 
perspective?

> I was looking at the Microblaze stuff earlier thinking someone must have 
> already solved this problem and avoided buying the 16550 for Linux.

Yeah I'll avoid the 16550 for as long as possible, for simple console 
stuff the uartlite should be fine.


>> http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
> 
> Is this a University related project perchance?

Yep - see my post a few lines down.  uClinux plus RTAI real-time 
extensions is the OS for our reconfigurable computing research platform.

Cheers,

John


Article: 58945
Subject: Re: Nios Ethernet Development Kit Problems
From: kempaj@yahoo.com (Jesse Kempa)
Date: 4 Aug 2003 17:04:41 -0700
Links: << >>  << T >>  << A >>
Hi Simon,

A colleague and I tried this with the following results: With the
older CS8900 card (10-base, used in the original Nios Ethernet Kit),
everything worked without errors. However, in the newer daughter card
(LAN91C111) we saw the same behavior.

This is really due to how we reset the two chips. With the original
Ethernet Kit, we would boot the MAC into "promiscuous mode" to receive
all packets, whether they were intended for our Nios board or not.
Primarily for reasons of efficiency (fewer interrupts, less CPU
overhead), we disabled promiscuous mode during bootup in the LAN91C111
driver. For applications such as nedk_bridge (where we just blindly
pass packets between the two Ethernet MACs), this causes some of the
packets to be igored, leading to the behavior you saw.

To get around this, call "set promiscuous" routine that is built into
our low-level MAC driver (lan91c111.c). Here is the modification to
nedk_bridge.c:

int main(void)
{
   int result;
   globals g;   // How polite we are, the globals aren't really
global!
   int i;

   // Snip: code to reset each Ethernet MAC & do error check

   // Set promiscuous "on" for "lan91c111_0"
   nr_lan91c111_set_promiscuous(na_lan91c111_0,0,1);

   // Set promiscuous "on" for "lan91c111_1"
   nr_lan91c111_set_promiscuous(na_lan91c111_1,0,1);


   // Rest of the code un-changed....

   ...
}

Good luck with your project.

Jesse Kempa
Altera Corp.
jkempa at altera dot com


"Simon Graham" <sgra070@xtra.co.nz> wrote in message news:<Ud0Xa.104068$JA5.2273965@news.xtra.co.nz>...
> Hi,
> 
> I'm trying to use stacked 100Mbit ethernet modules with the Nios Development
> Kit (Apex 20K) to create a secure firewall/bridge device for a university
> project.
> 
> However, I can't even get the example application included with the kit,
> "nedk_bridge.c" to work.
> 
> I have the nedk_bridge program running on the Apex board. Each ethernet
> module is connected via crossover cable to a PC. I then try doing a simple
> ping from one PC to the other and view the results using the Ethereal packet
> sniffer:
> 
<snip>
 
> The 1st PC sends the ARP request, the 2nd PC receives it, replies to the
> request, but the 1st PC never recieves the reply. The Nios for some reason
> never sends the final packet. If I initiate the ping from the other PC, the
> same thing happens - the first three packets are sent, but the last one is
> dropped.
> 
> Is the Nios even capable of functioning for the purpose I want to use it
> for? I noticed that the Nios always initializes the ethernet modules in
> half-duplex mode. Altera themselves give frustratingly little info about
> this.
> 
> I am using Quartus II 2.2, SOPC builder 2.52 (Nios CPU version 2.1), and
> Nios EDK 2.0 (LAN91C111 modules).
> 
> Thanks,
> 
> Simon

Article: 58946
Subject: Re: More VHDL issues..
From: rickman <spamgoeshere4@yahoo.com>
Date: Mon, 04 Aug 2003 20:51:35 -0400
Links: << >>  << T >>  << A >>
I added a variable to calculate a time for a wait statement in a
testbench and am not getting this error from ModelSim...

  Signal arm_command is read by the VITAL process but is NOT in the
sensitivity list

This is the line of code producing the error...

  WaitTime := (ARM_command.RelTime - (now - CurrentTime));

I follow this up with a check for negative values before using in the
wait.  ARM_command is a signal and WaitTime and CurrentTime are
variables.  And of course all these objects are of type time.  This same
calculation done directly in the wait statement gives no error.  


-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 58947
Subject: Re: LCD and step-up DC-DC converter.
From: Rob Judd <judd@ob-wan.com>
Date: Tue, 05 Aug 2003 12:47:15 +1000
Links: << >>  << T >>  << A >>
Amontec Team wrote:
> 
> Hi,
> 
> I have to connect a LCD-I2C to my FPGA.
> My LCD can be supplied only with 5V, and I have only a 3.3V.
> 
> Do you know a low cost step-up dc-dc converter solution.
> 
> I only need 2 mA as output current.

Look around for a simple charge-pump circuit.

Rob

Article: 58948
Subject: Re: 'Virtual Grounds'
From: hmurray@suespammers.org (Hal Murray)
Date: Tue, 05 Aug 2003 03:51:33 -0000
Links: << >>  << T >>  << A >>
>Not "all", just one extra per Vcco power/ground pin pair is all that is required
>to reduce ground bounce by another 20% (roughly).  The IO is set to a strong
>standard (ie GTL, PCI, CMOS 24 mA, etc.) and set to a logic '0'.  The pin is
>connected to the ground plane just like a ground pin.  Adding pins past the
>first leads to a very small improvement (not worth it).

Does it do any good to use a similar setup for power?

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 58949
Subject: Re: Tiny TCP/IP stack and tiny MAC controller on FPGA for direct download to S(D)RAM memory
From: hmurray@suespammers.org (Hal Murray)
Date: Tue, 05 Aug 2003 04:00:36 -0000
Links: << >>  << T >>  << A >>
>The other thing is that networking switches employ hardware lookup
>(using CAM) to decide which port an incoming network frame should go out.
>A router could probably use a similar scheme to route a packet,
>avoiding a routing table in software(software means slow.)

How does that table/CAM get initialized?

I'd suggest putting hacks like that on the back burner until the
initial code is working.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.




Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search