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 55825

Article: 55825
Subject: Modular Design: Map error
From: eduwenzel@yahoo.com.br (=?ISO-8859-1?Q?Eduardo_Wenzel_Bri=E3o?=)
Date: 20 May 2003 13:00:28 -0700
Links: << >>  << T >>  << A >>
Hi

I developed a medium project size that using Modular Design flow to
create a dynamic reconfigurable system. Specifically, I create a
memory controller that using a reconfigurable client circuit (fixed
and reconfig. modules). I fixed all the bus macros on the FPGA in UCF
file to communicate both modules. However, when the Active Modular
Phase of Modular Design is performed, the MAP tool issues the
following error:

ERROR:MapLib:492- Create a dummy tbuf in the context connected to
signal data_m_dup0 with a location constraint to a single site.

This signal is created after logic synthesis by Leonardo Spectrum
tool.
"data_m_dup0" is connected on the data_m signal.

data_m <= dataout when (pr_st_memctl=write_capture) else
(others=>'Z');

"write_capture" is a state. I inserted the code above because I
thougth it was necessary to help for understanding the problem.

I appreciate any kind of help.

Best regards 

Eduardo Wenzel Brio
Catholic University of Rio Grande do Sul state - PUCRS
Porto Alegre city
Brazil

Article: 55826
Subject: Re: SID chip describtion
From: "MikeJ" <support@{nospam}fpgaarcade.com>
Date: Tue, 20 May 2003 22:26:36 +0100
Links: << >>  << T >>  << A >>
> I know that one, actually it is very far from being detailed enough.

Depends how close you want to get - If 'very' then you will have to emulate
the nasty analogue bits which is going to be almost impossible (?)

try here for some more info and the interview - I have to admit it was the
interview I remember reading, not the patent document.
http://stud4.tuwien.ac.at/~e9426444/sidtech.html

> Additional and important information on the digital part of the SID
> is available in the interview with Bob Yannes somewhere one the web.
> However, there are still open questions about the more analog parts
> of the SID.
>
>



Article: 55827
Subject: Re: a (PC) workstation for FPGA development
From: Ben Twijnstra <btwijnstra@SPAM.ME.NOT.chello.nl>
Date: Tue, 20 May 2003 22:17:16 GMT
Links: << >>  << T >>  << A >>
Hi Ray,

> I agree with your sentiments regarding Linux.  It is also worth noting
> that you can run just about anything under the windoze with a fairly
> simple install.  Many apps need a considerable amount of set up to get to
> run under Lixux.

Installing Quartus II 2.2 for Linux from CD at this point is no more than
mounting the CD, running the install.sh script, answering one question (the
installation path), and sitting back while a lot of stuff gets written to
disk. I have done several installations myself and it truly is that simple,
if you don't count setting a few environment variables like LM_LICENSE_FILE
and suchlike, but that's a one-minute job as well.

The UNIX installs of the older versions (prior to Quartus II 1.0 sometime in
2001) were a true pain in the rear, I'll grant you that. While still
working for Altera I spent many days installing Quartus in some form or
another, reconfiguring kernel parameters of compute servers that were
supposedly not to be rebooted, setting obscure environment variables etc
etc. Very educational but not much fun. Luckily these days seem to be over.
Ever since Altera dropped the ObjectStore database manager things have gone
uphill very quickly.

I've also found that Quartus for Linux is pretty distribution-independant
(it even contains its own fonts, just to be sure), even though it's only
officially supported under RedHat 7.1. I've successfully run it on RedHat
7.1, 7.3 and 8.0 (using it on RedHat 9 crashes instantly at this point -
but then again the ReadHat 9 kernel is so heavily modified that even Linux
Torvalds would have trouble recognizing it), a version of Mandrake I don't
recall, Suse 8.1 and Gentoo Linux 1.4rc4 (my current favourite) in
bleeding-edge mode.

My experience with Modelsim under Linux is likewise, and so is my experience
with FPGA Connector (a really cool tool to settle pinout discussions
between me and my PCB layout guy once and for all), so I guess that Linux
installation and maintenance trouble is pretty much a myth - as long as you
have had some basic Linux or Unix training.

Best regards,



Ben


Article: 55828
Subject: Re: SID chip describtion
From: "Karl de Boois" <karlIGNORETHISPART@chello.nl>
Date: Wed, 21 May 2003 00:20:38 +0200
Links: << >>  << T >>  << A >>
Check out: www.fpga.nl & Jester

Karl.

"Daniel Fichtner" <daniel2323de@yahoo.de> wrote in message
news:cd8e70cd.0305180532.1801e4b0@posting.google.com...
> hi,
>
> do you know if there is a vhdl description or any other (synthesizable)
> describtion of the SID chip (6581/6582) ??
>
> thanks and bye



Article: 55829
Subject: Re: OK I am pissed off with Xilinx webpack.
From: Jan Panteltje <panteltje@yahoo.com>
Date: Tue, 20 May 2003 22:30:04 GMT
Links: << >>  << T >>  << A >>
On a sunny day (20 May 2003 10:36:55 -0700) it happened bretwade@earthlink.net
(Bret Wade) wrote in <2d91c07d.0305200936.305782c7@posting.google.com>:

>Jan Panteltje wrote:
>
>> ERROR:Place:1993 - Components udc0_uf10_N324 and udc0_N1466 are using the
>>    F5/F6MUX resources. The component udc0_uf10_N324 is part of a carry chain
>>    macro. Please RLOC components udc0_uf10_N324 and udc0_N1466 together.    
>
>I haven't seen this particular error before but I believe I can
>explain it. The component "udc0_uf10_N324" contains a portion of two
>different multi-slice shapes, a carry chain structure and an F5/F6MUX
>structure. Apparently the placer is having problems reconciling the
>placement requirements of both shapes and is asking for help via the
>use of RLOC constraints that would guide the relative placement of the
>logic involved.
>
>There are other possible solutions depending on the root cause of the
>problem. If the two shapes ended up sharing the same slice due to an
>unrelated pack then anything that blocked that unrelated pack would
>avoid the problem. Using a larger device would work (and would also be
>a good test of the unrelated pack theory) but another way would be to
>assign one of the shapes to an area group and then set a "compression"
>attribute of zero which will block unrelated packs for that logic.
>There is no need to actually define a range to the area group.
>
>Example UCF syntax:
>INST "some/hierarchy" AREA_GROUP = AG1 ;
>AREA_GROUP "AG1" COMPRESSION = 0 ;
>
>This trick can also be used to guard critical logic from unrelated
>packs which can lead to conflicting placement needs WRT timing.
>
>Bret
>
Thank you
Jan
PS yes, reducing the size (by omitting stuff) makes some of these
errors disappear.
So I think you are right about a larger FPGA.

Article: 55830
Subject: Re: a (PC) workstation for FPGA development
From: Ray Andraka <ray@andraka.com>
Date: Wed, 21 May 2003 03:16:36 GMT
Links: << >>  << T >>  << A >>
Ben,

I wasn't referring to the CAE tools as much as to all the other stuff you need
on the computer to do business.  These include the CAE stuff of course, but also
a word processor (shouldn't be too much a problem, but might be compatability
issues with cusotmers), Matlab (needed for DSP apps), something to write PDF
files (Adobe Acrobat), a spreadsheet (Excel)(used for various things in the
course of a design), and in the case of a consulting business like mine, it also
includes quickbooks...  The point is there is an awful lot of 'standard' stuff
out there that is much more hassle to get working under Linux than on an windoze
machine.  The CAE software probably has more support for running under Linux
than does much of the other stuff that still needs a home in order to have a
complete suite.  Regarding the CAE stuff, Windows does have a much larger user
base, so the chances of a bug being reported and dealt with are greater than
under Linux.  I do enough debug of the FPGA software already.

Ben Twijnstra wrote:

> Hi Ray,
>
> > I agree with your sentiments regarding Linux.  It is also worth noting
> > that you can run just about anything under the windoze with a fairly
> > simple install.  Many apps need a considerable amount of set up to get to
> > run under Lixux.
>
> Installing Quartus II 2.2 for Linux from CD at this point is no more than
> mounting the CD, running the install.sh script, answering one question (the
> installation path), and sitting back while a lot of stuff gets written to
> disk. I have done several installations myself and it truly is that simple,
> if you don't count setting a few environment variables like LM_LICENSE_FILE
> and suchlike, but that's a one-minute job as well.
>
> The UNIX installs of the older versions (prior to Quartus II 1.0 sometime in
> 2001) were a true pain in the rear, I'll grant you that. While still
> working for Altera I spent many days installing Quartus in some form or
> another, reconfiguring kernel parameters of compute servers that were
> supposedly not to be rebooted, setting obscure environment variables etc
> etc. Very educational but not much fun. Luckily these days seem to be over.
> Ever since Altera dropped the ObjectStore database manager things have gone
> uphill very quickly.
>
> I've also found that Quartus for Linux is pretty distribution-independant
> (it even contains its own fonts, just to be sure), even though it's only
> officially supported under RedHat 7.1. I've successfully run it on RedHat
> 7.1, 7.3 and 8.0 (using it on RedHat 9 crashes instantly at this point -
> but then again the ReadHat 9 kernel is so heavily modified that even Linux
> Torvalds would have trouble recognizing it), a version of Mandrake I don't
> recall, Suse 8.1 and Gentoo Linux 1.4rc4 (my current favourite) in
> bleeding-edge mode.
>
> My experience with Modelsim under Linux is likewise, and so is my experience
> with FPGA Connector (a really cool tool to settle pinout discussions
> between me and my PCB layout guy once and for all), so I guess that Linux
> installation and maintenance trouble is pretty much a myth - as long as you
> have had some basic Linux or Unix training.
>
> Best regards,
>
> Ben

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 55831
Subject: Re: a (PC) workstation for FPGA development
From: "B. Joshua Rosen" <bjrosen@polybus.com>
Date: Tue, 20 May 2003 23:50:55 -0400
Links: << >>  << T >>  << A >>
On Tue, 20 May 2003 12:12:18 -0400, Bob Perlman wrote:

> On 19 May 2003 02:01:50 -0700, tsvika.hirst@minicom.com (Tsvika Hirst)
> wrote:
> 
>>I need to specify a workstation that will use for FPGA development
>>(around 300K gates) i.e. simulate, synth, place and route flow (e.g.
>>Foundation ISE + ModelSim XE). I plan to use RedHat Linux, as I was told
>>it improves stability and 30% performance relative to Windows2000.
> 
> I use a dual-processor setup myself, with Windows 2000 O/S.  Nothing
> against Linux, but using an O/S that a lot of other users run makes it
> (slightly) more likely that any problems I encounter have already been
> tripped over by someone else.
> 
> For those of you with dual-processor systems, a question: which
> motherboard are you using?  I'm running an old Asus CUV4X-D with two
> 1GHz Pentium IIIs and 1.5GB of memory--kind of ancient, but it works
> very well.   What are today's best choices for dual-processor boards?
> 
> Bob Perlman
> Cambrian Design Works
 
I'm using a dual 2.6Ghz Xeon running Redhat 7.3. The most important thing is
RAM, get at least 1G but 2G is better. Don't worry about disk speed if you have
enough RAM there won't be any paging, get a big IDE disk with an 8M
buffer.

Article: 55832
Subject: Re: a (PC) workstation for FPGA development
From: jakespambox@yahoo.com (Jake Janovetz)
Date: 20 May 2003 21:21:52 -0700
Links: << >>  << T >>  << A >>
tsvika.hirst@minicom.com (Tsvika Hirst) wrote in message news:<a688cfa9.0305190101.79cfedaa@posting.google.com>...
> I need to specify a workstation that will use for FPGA development
> (around 300K gates) i.e. simulate, synth, place and route flow (e.g.
> Foundation ISE + ModelSim XE). I plan to use RedHat Linux, as I was
> told it improves stability and 30% performance relative to
> Windows2000.
> 
> I'm trying to set priorities to and find the tradeoffs between:
> Processor:  Single or Dual (e.g. Pentium IV 2.4GHz) 
> HDD type and speed: SCSI or ATA/EIDE (e.g. 18GB SCSI 10,000rpm or
> 15,000 rpm vs. 80GB ATA 7200rpm)
> RAM size: 512MB/1GB
> 
> I will very much appreciate your feedback.

If you're going to be doing a lot of work, I'd optimize my work
environment first.  That means a dual-head LCD setup.  You'd be amazed
at how much comfortable an LCD is to work with.  Likewise, dual-head
will save you gobs of time shuffling things around your desktop.

Now, Linux will buy you a speed gain but only if the software supports
it.  ISE doesn't right now.  I've seen big performance jumps using
Linux (over Windows) on the same machine but only in software
available native to Linux.

Dual processor will avoid bogging down your machine when it is
crunching on a P&R or something, but for that I just use VNC.  I'll
bring up VNC to a Linux box or another Windows machine in one of my
heads, leave the other one on the Xilinx job and it's pretty smooth. 
I don't sponsor the dual-processor approach for most things.  It is
nice for multi-user UNIX setups so that folks don't affect each other,
but for a single-user setup with little software support for
multiprocessor, put your money elsewhere.

SCSI is great for multi-threaded file access such as file serving, but
won't buy you much in a single-user environment.  It will get you a
little, but for Xilling work, the processes aren't I/O limited,
they're CPU limited.

Bottom line-- get the fasted single-CPU setup you can afford with
quality components and speedy memory (and lots of it) to keep the
Xilinx environment efficient.  Run a dual-head LCD setup to keep your
WORK environment efficient.  If you want to do other things while the
jobs are running, get another PC (no monitor) and use VNC.

   Jake

Article: 55833
Subject: Re: Thermal problems with large FPGA BGA's
From: Mario Trams <Mario.Trams@informatik.tu-chemnitz.de>
Date: Wed, 21 May 2003 09:07:24 +0200
Links: << >>  << T >>  << A >>
Newsgroup wrote:

> Has anyone experience of BGA balls separating from the PCB pads when
> cycling the boards at thermal extremes e.g. -40degC to +85degC.
> I understand that there are cases where outer balls/pads have been seen to
> separate on physically large BGA devices but need to understand what
> physical size this is i.e. 35mm, 40mm?? This should be reduced by going
> for well matched Tce of BGA substrate to PCB material but are there other
> issues worth considering.

Did you visually check the PCB behavior during operation at these 
extremes (especially the lower end)?

When PCBs get warmed up differently on both sides they tend to bend
and look like a slice of dry bread. 
Also check that the PCB layer stack is built up symmetrically. 
Especially in view of ground an power planes. When a majority of 
planes is located on one side of the PCB, it will be deformed 
as well depending on temperature (even if the board has the same
temperature on both sides).

Regards,
Mario




Article: 55834
Subject: Re: Using GERMS monitor with NIOS CPU on non-Altera board
From: fredrik_he_lang@hotmail.com (Fredrik)
Date: 21 May 2003 00:11:23 -0700
Links: << >>  << T >>  << A >>
Hi Yevgeny,
Usally I put the Germs monitor into my bootrom (M4k or ESB depending
if I am using APEX or Cyclone/Stratix) block in the FPGA. This is done
by adding a on-chip memory (RAM/ROM. Then select size to 2kByte and
add content GERMS monitor. When you then do a build the germs monitor
will be compiled and put into this memory content. Germs do not need
FLASH to function and I can help with storing sw into exteral flash
but can also be used to start your own SREC files.
Cheers
Fredrik

 
syevgen1@hotmail.com (Yevgeny K.) wrote in message 
news:<6c3628cf.0305201149.15e36883@posting.google.com>...
> Hello all.
> 
> We are using Altera NIOS CPU with non-Altera PCI card with Altera FPGA
> (Gidel PROC20K board without flash memory).
> We are trying to use GERMS monitor, but it doesn't work - the "nios-run"
> script doesn't find a target (no responce from the GERMS).
> All the "hardware" was checked over and over - it's OK for sure.
> We looked at the GERMS source code, and it looks like it requires flash
> memory to exist and the program that GERMS receives is uploaded to flash,
> so this maybe the explanation why in our case (no flash on board) it 
> doesn't work.
>    The question is, can the GERMS monitor be somehow "reconfigured"?
> In other words, can we make it work somehow without flash, by uploading the 
> program to the RAM on the FPGA itself?
> Has anybody tried something like this?
> 
> Thanks in advance

Article: 55835
Subject: Opteron support?
From: Petter Gustad <newsmailcomp5@gustad.com>
Date: 21 May 2003 10:37:52 +0200
Links: << >>  << T >>  << A >>
"B. Joshua Rosen" <bjrosen@polybus.com> writes:

> I'm using a dual 2.6Ghz Xeon running Redhat 7.3. The most important
> thing is RAM, get at least 1G but 2G is better. Don't worry about
> disk speed if you have enough RAM there won't be any paging, get a
> big IDE disk with an 8M buffer.

You're getting very close to the 2/3.xGB limit here. As design/tool
complexity increases you might need to migrate to a 64-bit CPU.

Does anybody know which tools will be available in 64-bit version for
the AMD Opteron? The only one I know of is Synopsys VCS:

http://www.synopsys.com/news/announce/press2003/vcs_amd_pr.html

Most of the other Synopsys tools are available in 64-bit versions
under Solaris/SPARC so I would expect most of these to migrate to
X86-64/Linux.

Petter
-- 
________________________________________________________________________
Petter Gustad         8'h2B | ~8'h2B        http://www.gustad.com/petter

Article: 55836
Subject: CHES 2003: accepted papers etc.
From: cpaar@crypto.ruhr-uni-bochum.de (Christof Paar)
Date: 21 May 2003 11:04:38 GMT
Links: << >>  << T >>  << A >>


Here is an update on the 5th Workshop on Cryptographic Hardware
and Embedded Systems (CHES 2003):

1) The List of Accepted Papers is available on the CHES web site:

                       www.chesworkshop.org

2) We have three invited speakers:

Hans Dobbertin, Ruhr-University Bochum, Germany
Adi Shamir, Weitzman Institute, Israel
Frank Stajano, Cambridge University, UK

3) Registration information is also on the CHES web site. You will find
information about accommodation and traveling too.


We will be happy to assist if you have other questions regarding CHES
2003.

Regards, Christof Paar

============================================
CHES 2003 CHES 2003 CHES 2003 CHES 2003 CHES
            www.chesworkshop.org
============================================
Prof. Christof Paar
Chair for Communication Security
Dept. of Electr. Eng. & Information Sciences
Ruhr-Universitaet Bochum
44780 Bochum, Germany

URL: www.crypto.rub.de


Article: 55837
(removed)


Article: 55838
Subject: Re: Register in FPGA
From: "Jens Nowack" <its.me.hates-spam@uni.de>
Date: Wed, 21 May 2003 14:53:34 +0200
Links: << >>  << T >>  << A >>
Ray Andraka" <ray@andraka.com> schrieb im Newsbeitrag
news:3EBF8D29.C2D5FBA5@andraka.com...
> You can often simplfy readback of control registers that are written only
by the
> microcontroller by putting a shadow 'register' in RAM in addition to the
> physical register.  The physical register provides the individual bits to
the
> circuit while a RAM which is simultaneously written provides a copy of the
data
> in a convenient form for easy readback.  If you have a small number of
status
> registers whose contents are updated by the FPGA logic, you can sometimes
use a
> dual port memory for the shadow register with the second port hardwired
for
> write at a specific address so that the status info winds up in the proper
> location in the shadow RAM.
>

Thanx for your information. I have tried to understand your specification
but I think I need more information.

The basic principle what I need is a Dual-Port-Ram. The microcontroller
selects via address bus, WR, CS, RD the register in the FPGA, respectively
in (DUAL)-RAM. But the other side of DUAL-RAM should be direct useable
without addressing the register.
A control register are written by the C and read by the FPGA - the status
register are written by the FPGA and read by C.

I think a little example would be very useful.

Until now I have created a 8 Bit wide register block by programming a
discrete register (with CS, WR, RE, data_io (C), data_io(FPGA), rm
(register mode [status/config]. Then i have combined several 8 Bit registers
to a block of e.g. 16 or more. To select the register I have developed a
simple address decoder.
In principle it runs, but I need more than 16 registers, e.g. 48 or more,
and then this method becomes to complex.

The other way would be to use a DUAL-RAM by addressing every time I need a
config information and store it in the actual process. Is it clever??

Maybe, my idea to solve this problem could be the wrong way. I am open for
other methods of resolutions.

Best regards





Article: 55839
Subject: Re: FPGA: Feasibility of Memory testing
From: Falser Klaus <kfalser@IHATESPAMdurst.it>
Date: Wed, 21 May 2003 16:14:23 +0200
Links: << >>  << T >>  << A >>
In article <8679149d.0305190557.2eb2cd3c@posting.google.com>, Henning.Bahr@ncl.ac.uk says...
> Hello there!
> 
.. snip .. 
> Is it a problem for the FPGA to drive 9 memories in parallel? If it's
> feasible to use an FPGA, which products would be most suitable?
> Many thanks in advance for your help.
> Kindest Regards, 
> Henning
> 

If your question was if you can connect the 9 chips directly to the FPGA then the 
answer is :
It depends on the input capacitance of the memory chip.

A typical SDRAM chip has max. 5 pF per pin. This gives a worst case of 45 pF load and 
can slow down your signal.

Best regards
  
-- 
Klaus Falser
Durst Phototechnik AG
kfalser@IHATESPAMdurst.it

Article: 55840
Subject: Re: Register in FPGA
From: Mario Trams <Mario.Trams@informatik.tu-chemnitz.de>
Date: Wed, 21 May 2003 16:30:52 +0200
Links: << >>  << T >>  << A >>
Jens Nowack wrote:

> Ray Andraka" <ray@andraka.com> schrieb im Newsbeitrag
> news:3EBF8D29.C2D5FBA5@andraka.com...
>> You can often simplfy readback of control registers that are written only
> by the
>> microcontroller by putting a shadow 'register' in RAM in addition to the
>> physical register.  The physical register provides the individual bits to
> the
>> circuit while a RAM which is simultaneously written provides a copy of
>> the
> data
>> in a convenient form for easy readback.  If you have a small number of
> status
>> registers whose contents are updated by the FPGA logic, you can sometimes
> use a
>> dual port memory for the shadow register with the second port hardwired
> for
>> write at a specific address so that the status info winds up in the
>> proper location in the shadow RAM.
>>
> 
> Thanx for your information. I have tried to understand your specification
> but I think I need more information.
> 
> The basic principle what I need is a Dual-Port-Ram. The microcontroller
> selects via address bus, WR, CS, RD the register in the FPGA, respectively
> in (DUAL)-RAM. But the other side of DUAL-RAM should be direct useable
> without addressing the register.
> A control register are written by the C and read by the FPGA - the status
> register are written by the FPGA and read by C.
> 
> I think a little example would be very useful.

Such a dual-ported RAM you need is usually not available, unfortunately. 
The scenario proposed by Ray is only useful, when you have a couple 
of control registers (I'm refering to your terminology) that need to
be read/writable by the controller. In this case you implement both
your actual control registers and the RAM (that does not need to 
be dual-ported).

When the controller is writing something, it is written into the 
actual control registers AND into the RAM as well.
When the controller is reading something, you would just return 
the data from the RAM. This safes you to implement this nasty 
multiplexer stuff.

The actual problem are the status registers, however. When you want to 
read them by the controller, you have to select the right one by 
a mux. This can also be comined with the described shadow-RAM 
method (i.e. when you are reading, you sometimes return the 
RAM contents and sometimes status register contents).

> Until now I have created a 8 Bit wide register block by programming a
> discrete register (with CS, WR, RE, data_io (C), data_io(FPGA), rm
> (register mode [status/config]. Then i have combined several 8 Bit
> registers to a block of e.g. 16 or more. To select the register I have
> developed a simple address decoder.
> In principle it runs, but I need more than 16 registers, e.g. 48 or more,
> and then this method becomes to complex.
> 
> The other way would be to use a DUAL-RAM by addressing every time I need a
> config information and store it in the actual process. Is it clever??

It depends on your application. 
But generally there's the same problem with the status registers. 
Of course, you could send some kind of command to some back-end 
logic that writes the value of a certain status register into the
dual-ported RAM. But here you are just moving the mux problem 
deeper into the FPGA (farther away from the controller interface).

> Maybe, my idea to solve this problem could be the wrong way. I am open for
> other methods of resolutions.

Perhaps some useful hints:
 - avoid read/write registers; implement just read-only and write-only
   registers
 - try to make use of tristatable busses (if your FPGA does support
   this feature) in order to create multiplexers; this saves a lot
   of logic resources

Regards,
Mario


 

Article: 55841
Subject: Re: a (PC) workstation for FPGA development
From: Duane Clark <junkmail@junkmail.com>
Date: Wed, 21 May 2003 08:08:47 -0700
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> Ben,
> 
> I wasn't referring to the CAE tools as much as to all the other stuff you need
> on the computer to do business.  These include the CAE stuff of course, but also
> a word processor (shouldn't be too much a problem, but might be compatability
> issues with cusotmers), Matlab (needed for DSP apps), something to write PDF
> files (Adobe Acrobat), a spreadsheet (Excel)(used for various things in the
> course of a design), and in the case of a consulting business like mine, it also
> includes quickbooks...  The point is there is an awful lot of 'standard' stuff
> out there that is much more hassle to get working under Linux than on an windoze
> machine...

My experience over quite a few years is that the CAE software itself is 
the biggest hassle, regardless of the platform. Trying to get it 
running, hitting and figuring out workarounds for bugs, etc. And that is 
only compounded when organizations like Xilinx change the software 
completely every few years.

I think anyone who can figure out CAE software can handle Linux with no 
problem. And all those tools, though not the brands, you mentioned are 
already available for Linux. I do all phases of my business exclusively 
on Linux. I only have Windows around for customers who want something 
that runs only on Windows, and for Wine development testing when I have 
some spare time.


-- 
My real email is akamail.com@dclark (or something like that).


Article: 55842
Subject: Re: problem with modelsim 5.7d on winXP system
From: Michael Bills <mbbillsREMOVE_THIS@raytheon.com>
Date: Wed, 21 May 2003 08:10:21 -0700
Links: << >>  << T >>  << A >>
Make sure your environment variables are correct. It believe it has to 
point to your license file or license server or both. I had problems 
with Synplify because of an environment variable setting. Also, 
something may have changed when you upgraded. Try going back to your 
older version. Try running them under Win2000 if it is available, I run 
modelsim and synplify under win2000 without any problems.

Dennis Maasbommel wrote:
> From: "Dennis Maasbommel" <aabbccdd00@hotmail.com>
> Subject: Modelsim generating (Sigsegv BadPointer Access)-error on winXP
> Date: zondag 18 mei 2003 22:59
> 
> Hello again, you all !
> 
> The advice on my previous post (see below) was to upgrade to Modelsim
> version 5.7.
> So I did, but unfortunately, the program running on my winXP system, still
> collapses when
> I try to add signals to the wave window. And here I have no solution or
> workaround yet.
> 
> It occured to me, that perhaps the system collapses if I'd try to add
> signals to the wavetable,
> if they haven't been forced a particular value at all. So I forces the
> signals a value and simulated
> the model for some time, and THEN added the signals to the wave table.
> Unfortunately, still no success.
> 
> Is somebody able to help this student out here?
> Thanks in advance.
> 
> Best regards,
> Dennis Maasbommel
> 
> 
> 
> 
> ----- Original Message -----
> From: "Dennis Maasbommel" <aabbccdd00@hotmail.com>
> Newsgroups: comp.arch.fpga
> Sent: Thursday, May 08, 2003 3:01 AM
> Subject: Modelsim generating (Sigsegv BadPointer Access)-error on winXP
> 
> 
> 
>>Hi Folks,
>>
>>Using FPGA Advantage V5.4 on my WinXP SP1 system,
>>I am having some problems with the integrated modelsim (v5.6d)
>>component.
>>
>>After a succesful compilation, I try to simulate the model,
>>But with many models I get this error
>>
>>   ** Fatal: (SIGSEGV) Bad pointer access.
>>
>>
>>I searched using Google and it took me to the GNU C Library,
>>where this error was explained; From this point my guess is
>>that maybe Modelsim is not suitable for WinXP yet.
>>
>>I have tried all the compatibilty modes
>>(i.e. win95, win98/winME, winNT4 SP5, win2k)
>>but neither of these modes prevented modelsim from
>>generating this error.
>>
>>I have also tested a very simple model, which COULD be simulated,
>>but unfortunately Modelsim collapsed (program exits without further
> 
> notice)
> 
>>when I wanted to add signals to the wave-table. I guess maybe this has
>>someway the same cause as the 'Bad Pointer Access'-error.
>>
>>Beside this behavior, I have no other clue that my installation
>>version is corrupted
>>
>>Does any of you have experienced likewise problems with this tool,
>>and/or know how to solve these problems? I would be glad to hear it!
>>
>>Best Regards,
>>Dennis Maasbommel
>>
>>
> 
> 
> 
> 
> 
> 


Article: 55843
Subject: BC pipelined loop synthesis
From: Charles Wagner <Charles.Wagner@irisa.fr>
Date: Wed, 21 May 2003 17:34:49 +0200
Links: << >>  << T >>  << A >>
I use Cocentric SystemC Behavioral Compiler to synthesise a SystemC 
specification implementing
 a  N stages pipelined datapath , with loops (for statement) and 
pipeline_loop command.
Target technology is APEX20KE  FPGA.

This works fine with N<=4, but fails with N>4.
-- 
--  schedule -io cycle_fixed -effort low
--
-- Information: Mapping components to 
FPGA...........................................
.................................................................................................................

-- Error: Unable to communicate with FPGA Compiler II, launched from 
/soft/synopsys_hd/2001.08/fpga_compiler2/bin/fc
--  2_shell (HLS-608)

Anybody has an idea why ?

Thanks,

Charles


Article: 55844
Subject: Programming Altera EPC1 and EPC1441
From: edaudio2000@yahoo.co.uk (ted)
Date: 21 May 2003 08:41:40 -0700
Links: << >>  << T >>  << A >>
How does one program the Altera configuration devices EPC1 and 1441?

Can you use the standard parallel byteblaster cable, or do you need a
special programmer? if so, where cao I find some information?

Can't seem to find any information on the Altera CD.

Any ideas??

thanks all

Article: 55845
Subject: Re: a (PC) workstation for FPGA development
From: Ray Andraka <ray@andraka.com>
Date: Wed, 21 May 2003 17:33:53 GMT
Links: << >>  << T >>  << A >>
VNC is fine for text stuff.  It leaves quite a bit to be desired for looking at simulation traces though.

Jake Janovetz wrote:

> tsvika.hirst@minicom.com (Tsvika Hirst) wrote in message news:<a688cfa9.0305190101.79cfedaa@posting.google.com>...
> > I need to specify a workstation that will use for FPGA development
> > (around 300K gates) i.e. simulate, synth, place and route flow (e.g.
> > Foundation ISE + ModelSim XE). I plan to use RedHat Linux, as I was
> > told it improves stability and 30% performance relative to
> > Windows2000.
> >
> > I'm trying to set priorities to and find the tradeoffs between:
> > Processor:  Single or Dual (e.g. Pentium IV 2.4GHz)
> > HDD type and speed: SCSI or ATA/EIDE (e.g. 18GB SCSI 10,000rpm or
> > 15,000 rpm vs. 80GB ATA 7200rpm)
> > RAM size: 512MB/1GB
> >
> > I will very much appreciate your feedback.
>
> If you're going to be doing a lot of work, I'd optimize my work
> environment first.  That means a dual-head LCD setup.  You'd be amazed
> at how much comfortable an LCD is to work with.  Likewise, dual-head
> will save you gobs of time shuffling things around your desktop.
>
> Now, Linux will buy you a speed gain but only if the software supports
> it.  ISE doesn't right now.  I've seen big performance jumps using
> Linux (over Windows) on the same machine but only in software
> available native to Linux.
>
> Dual processor will avoid bogging down your machine when it is
> crunching on a P&R or something, but for that I just use VNC.  I'll
> bring up VNC to a Linux box or another Windows machine in one of my
> heads, leave the other one on the Xilinx job and it's pretty smooth.
> I don't sponsor the dual-processor approach for most things.  It is
> nice for multi-user UNIX setups so that folks don't affect each other,
> but for a single-user setup with little software support for
> multiprocessor, put your money elsewhere.
>
> SCSI is great for multi-threaded file access such as file serving, but
> won't buy you much in a single-user environment.  It will get you a
> little, but for Xilling work, the processes aren't I/O limited,
> they're CPU limited.
>
> Bottom line-- get the fasted single-CPU setup you can afford with
> quality components and speedy memory (and lots of it) to keep the
> Xilinx environment efficient.  Run a dual-head LCD setup to keep your
> WORK environment efficient.  If you want to do other things while the
> jobs are running, get another PC (no monitor) and use VNC.
>
>    Jake

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 55846
Subject: Re: a (PC) workstation for FPGA development
From: Duane Clark <junkmail@junkmail.com>
Date: Wed, 21 May 2003 10:45:27 -0700
Links: << >>  << T >>  << A >>
Jake Janovetz wrote:
> ...
> Now, Linux will buy you a speed gain but only if the software supports
> it.  ISE doesn't right now.  I've seen big performance jumps using
> Linux (over Windows) on the same machine but only in software
> available native to Linux.
> 

My completely unscientific observation is that the Xilinx software runs 
just as fast under Linux as Windows. And after all, it is X86 software 
running on an X86, so unless there are a lot of API calls (which are a 
minor part of CAE processing) this would be expected.

-- 
My real email is akamail.com@dclark (or something like that).


Article: 55847
Subject: Evolvable Hardware Class at UCLA
From: "Steve Casselman" <sc_nospam@vcc.com>
Date: Wed, 21 May 2003 18:01:15 GMT
Links: << >>  << T >>  << A >>
Evolvable Hardware for Autonomous Systems

UCLA Extension, Los Angeles, CA

August 18-20

Lecturer: Dr. Adrian Stoica, Jet Propulsion Lab

http://www.uclaextension.org/unexVirtual.cfm?d=/shortcourses/summer2003/03SuP5502.cfm
-----------------
Evolvable Hardware (EHW) is a new field at the confluence of Reconfigurable
Hardware, Automatic Design, Artificial Intelligence and Autonomous Systems.
Its main objective is the development of a new generation of hardware,
self-configurable and evolvable, environment-aware, which can adaptively
reconfigure to achieve optimal signal processing, survive and recover from
faults and degradation, improve its performance over lifetime of operation.
EHW techniques have already proven successful in design automation,
automated calibration and tuning, and on-line adaptation of hardware
systems.

This course presents the fundamentals of EHW technology, overviews existing
and previews future reconfigurable devices, explains algorithms and
techniques for guiding self-configuration, illustrates operation with
evolvable hardware experiments, provides application examples, covers
specific difficulties in doing evolution with hardware in the loop and ways
of addressing them.

The course is intended for engineers, managers, and other professionals who
are involved in development and utilization of intelligent and adaptive
hardware (flexible and survivable). It also targets those involved in the
development and utilization of autonomous systems, automated design tools
and platforms, automatic calibration and tuning. At the end of the course
the attendants will be able to design evolvable hardware systems for their
particular area of application.

No special pre-requisite.
--------------------
Lecture notes are distributed in the first day of the course.
------------------
Adrian Stoica, PhD, Principal Member of the Technical Staff, and Manager for
Computing Devices in the Space Information Systems Technology Office at the
Jet Propulsion Laboratory (JPL), California Institute of Technology. Dr.
Stoica has over 17 years of R&D and technology development in adaptive and
learning techniques for autonomous intelligent systems. The last seven years
he was has been with the Advanced Computing Technologies Group at JPL, where
he has lead multi-million dollar technology R&D projects for NASA and DOD,
in the areas of adaptive hardware for space autonomous systems (including
evolvable/reconfigurable hardware, adaptive/learning hardware and sensor
fusion hardware), and next-generation robots (focusing on rover intelligence
and robot sensory-motor control). He and his team have designed and
demonstrated three generations of evolution-oriented chips. Dr. Stoica has
authored over 70 papers, was keynote speaker at several conferences, is
member of editorial board of several journals, taught conference tutorials
and short courses, and has chaired four conferences on evolvable hardware,
the latest being the 2002 NASA/DOD Conference on Evolvable Hardware. He is a
recipient of the 1999 Lew Allen Award, JPL's highest distinction for
excellence in research.
---------------

Course Program

Introduction to EHW
- EHW as Adaptive hardware
- Components of a EHW system
- EHW for flexibility and survivability of autonomous systems
- Automated design and adaptation by search/optimization techniques,
- Extrinsic and Intrinsic EHW

Reconfigurable and Morphable Hardware

- Reconfigurable hardware (switch-based). Devices, SW Tools, Potential for
EHW
- Field Programmable Gate Arrays (FPGA) - Xilinx examples
- Field Programmable Analog Arrays (FPAA) - Anadigm Examples
- Field Programmable Transistor Arrays (FPTA) - JPL examples
- Reconfigurable antennas
- Other reconfigurable structures
- Context-switching, speed of change, latency issues
- Morphable hardware (no switches). Fine changes and tuning.
- Morphable Materials and devices
- Polymorphic circuits

Algorithms for self-configuration and evolution
- General perspective on search, optimization and adaptation algorithms
- Essence of evolutionary algorithms
- Flavors: Genetic Algorithms, Genetic Programming
- Multi-criteria optimization, trade-offs, Pareto optimality

Demonstrations of Evolvable Systems
- Evolution on JPL EHW Testbed (platform for mixtrinsic evolution)
- Details of EHW Pack (SW tools), and NICE (Visualization tool)
- Evolution on JPL SABLES (Stand-Alone Board-Level Evolvable System)
o Half-wave rectifier, Filters, Digital circuits

Application Examples
- Programmable compensation for analog circuits (Optimal tuning)
- Programmable delays in high-speed digital circuits (Clock skew
compensation)
- Automated discovery - Invention by Genetic Programming (Creative Design)
- EDA Tools, analog circuit design
- Adaptation to extreme temperature electronics (Survivability by EHW)
- Fault-tolerance and fault-recovery
- Evolvable antennas (In-field adaptation to changing environment)
- Adaptive filters (Function change as result of mission change)


System Aspects
- Integration
- Need for upfront complete specifications
- Behavioral vs structural specification
- Languages for evolvable hardware
- Verification and validation
- On-line vs off-line evolution
- Techniques to reduce evaluation time
- Challenges, and open problems

Resources for EHW Engineers
- A guide to published literature and on-line resources
- Software tools
- Events



Article: 55848
Subject: CLKDLL: Dividing
From: Johan <grimaldi88@hotmail.com>
Date: Wed, 21 May 2003 11:30:17 -0700
Links: << >>  << T >>  << A >>
Hi
I have a 50 MHz clock that I would like to run in 5 MHz. Thus making it neccessary to use two clkdlls in serial. 

If I set the generic CLKDV_DIVIDE to 2 or use the default value, 2, the lock signal appears. But if I use any other valid number than 2 the lock signal does not appear even though the
division of the clock seams ok in the wavetrace. 

The same problem occurs both in ncsim and modelsim. 

My code and testbench can be found at http://bart.sm.luth.se/~johmat-8/ 

Regards
Johan


Article: 55849
Subject: FPGA design: firmware or hardware?
From: joefrese@hotmail.com (Joe Frese)
Date: 21 May 2003 12:26:38 -0700
Links: << >>  << T >>  << A >>
I've got a question of terminology for the group: is FPGA design
generally classified as hardware, firmware, or neither?  Most of the
designs I've worked on have served to interface firmware with
hardware.  It seems that firmware engineers like to think of FPGA
designs as more firmware, and that hardware engineers like to think of
FPGA designs as more hardware.  As an FPGA developer, though, I'm of
the mind that the unique design considerations of the technology
justify a new and separate category . . .

A coworker suggested the term "coreware," but apparently that's a
registered trademark of LSI Logic.  Is there another term with the
-ware suffix commonly used to refer to code (VHDL, Verilog, or
otherwise) intended to be implemented in an FPGA?

Joe



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