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 69750

Article: 69750
Subject: Re: Initialize Blockram from file
From: jon@beniston.com (Jon Beniston)
Date: 19 May 2004 07:26:47 -0700
Links: << >>  << T >>  << A >>
Daniel Köthe <d.koethespam@colour-control.com> wrote in message news:<c8f1te$9ir$1@news.eastlink.de>...
> Hello,
> i think in the last release of Xilinx Webpack 6.1 or 6.2 the abilitiy 
> has added to initialize a blockram from file by xst. But this feature is 
> not documented by xilinx or 1 don't found it.
> 
> Has anyone used this feature?

You can certainly do it using Core Gen. Also, if you look under
language templates in Project Navigator, you can do it with defparams:

   // RAMB16_S1: Virtex-II/II-Pro, Spartan-3 16kx1 Single-Port RAM
   // Xilinx  HDL Language Template version 6.1i

   RAMB16_S1 RAMB16_S1_inst (
      .DO(DO),      // 1-bit Data Output
      .ADDR(ADDR),  // 14-bit Address Input
      .CLK(CLK),    // Clock
      .DI(DI),      // 1-bit Data Input
      .EN(EN),      // RAM Enable Input
      .SSR(SSR),    // Synchronous Set/Reset Input
      .WE(WE)       // Write Enable Input
   );

   // The following defparam declarations are only necessary if you
wish to change the default behavior
   // of the RAM. If the instance name is changed, these defparams
need to be updated accordingly.

   defparam RAMB16_S1_inst.INIT = 1'h0;  // Value of output RAM
registers at startup
   defparam RAMB16_S1_inst.SRVAL = 1'h0; // Ouput value upon SSR
assertion
   defparam RAMB16_S1_inst.WRITE_MODE = "WRITE_FIRST"; // WRITE_FIRST,
READ_FIRST or NO_CHANGE

   // The following defparam INIT_xx declarations are only necessary
if you wish to change the initial
   // contents of the RAM to anything other than all zero's.

   defparam RAMB16_S1_inst.INIT_00 =
256'h0000000000000000000000000000000000000000000000000000000000000000;
 
Cheers,
JonB

Article: 69751
Subject: Re: Nios II Going Live...
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Wed, 19 May 2004 14:33:24 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <e87b9ce8.0405190623.168bb823@posting.google.com>,
Jon Beniston <jon@beniston.com> wrote:
>> The weird register window mechanism from NIOS (is it called NIOS1 now?) 
>> didn't work well in embedded processing markets.
>
>Well, you can hardly call it weird (at least one mainstream arch,
>SPARC, uses it), and in the embedded space, Tensilica have no problems
>selling their arch, which also features register windows.

Just because it is used, doesn't mean its a good idea.  Register
windows suck.  Register windows reinvented (rotating register file
from the IA64 suck as well).

If you want fast function-call save/restore, observe that going into a
cache or memory, you often have a wide interface, so the cost of
writing 4 ALIGNED words is the same as writing one, and have aligned 4
or aligned 8 load/store instructions.  Remember the FPGA mantra: Wires
are cheap, switching the wires is expensive.

>If you really want to sling some mud, my favourite part is where they
>talk about "Avoiding processor obsolescence"... Er, hasn't this has
>just made NIOS obsolete? How long before they change their minds
>again?

Nah, because NIOS1 will still be around.  One of the great things
about soft-cores is they are a bit easier to keep "in production"
compared with a hard core.

>Fair play to them, I didn't really think too much of NIOS, but if they
>really can push 200MHz with this, then I am impressed.

Looking at the talk at FPGA on some of the arch tricks used to make
the ALU so short in NIOS-1, it might be possible.



-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 69752
Subject: Re: Xilinx V2P: DCM and changing input clock
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 19 May 2004 07:48:09 -0700
Links: << >>  << T >>  << A >>
Sean,

Brute force!

As long as the locked signal is low, periodically reset the DCM, and see 
if the locked signal remains low.

It takes a little state machine, and it would have to run off the DCM 
CLKIN (which is OK, just assume it is running at 25 MHz to calculate how 
many counts you need to wait to make sure that LOCKED has gone high).

Also use the CLKIN_STOPPED bit, and if you use the DFS part of the DCM, 
use the CLKFX_STOPPED status bit as well (if anything goes wrong, reset 
the DCM).

(pseudo code below)

while CLKIN_STOPPED = 1 (clock is running)

      assert (reset for one clock)
      wait XX uSec

      check DCM:  DCM not operating? (check approp. status)
                       assert reset (for one clock)
                       wait XX uSec
                  else do nothing

      wait XX uSec (use one counter for all waits)

      go to check DCM



Austin

Sean Durkin wrote:
> Hi *,
> 
> I use several DCMs in my V2P7-design, and have the following problem:
> 
> After the FPGA is configured, the input clock is outside of DCM specs 
> (it's somewhere in the 1MHz-range). Of course, the DCMs can't achieve a 
> lock with this. Awhile later (the exact time is unknown) the input clock 
> is switched to 25MHz. In order for the DCMs to lock, I then have to 
> issue an external reset.
> 
> What I'd like is some way to do this automatically. Normally, I'd use 
> the status(1)-bit from the DCM, which should indicate the input clock 
> was lost while changing. But this bit is obviously only set when a lock 
> was achieved before and the clock is lost after that. If the DCM never 
> locks in the first place, the status-bit is never set.
> 
> The main problem here is that I don't know exactly when the input clock 
> will be changing, i.e. when I have to issue the reset.
> 
> Any ideas? Is there some clever way to do this I'm not seeing?
> 
> cu,
> Sean

Article: 69753
Subject: Antwort: Re: Xilinx WebPack 6 -> Error: 90:Portability <-- anyone can give
From: khiltrop@gesytec.de
Date: 19 May 2004 14:49:46 GMT
Links: << >>  << T >>  << A >>
Yes, I have been there. If I did not overlook something, there are error 
reports with the same number and keyword, however, from the impact 
programmer.

I have the error with 'translate' process.

Thanks anyway :-)

Klaus,
Have you been to the Xilinx website answer search thingy? I put
ERROR:Portability:90 into the search and had four answers appear.
Somewhere to start.
Cheers, Syms.

Article: 69754
Subject: Re: Nios II Going Live...
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 19 May 2004 07:53:55 -0700
Links: << >>  << T >>  << A >>
All,

If you can compile your code from c, who cares what the architecture is?

Sorry, but it really doesn't matter.

Speed, and ease of use are what counts in this business.

Apologies to processor architects, but unless you are doing a research 
project, hardly anyone cares anymore about these details.

At lunch the other day we were reminiscing about how the Z8000 never 
took off because they changed their architecture and instruction set 
completely from the Z80 and immediately alienated all of their customers 
(who were still programming in assembly language in those days).

Not like that anymore.

Austin

PS:  check out http://biz.yahoo.com/prnews/040518/sftu114_1.html


Nicholas C. Weaver wrote:

> In article <e87b9ce8.0405190623.168bb823@posting.google.com>,
> Jon Beniston <jon@beniston.com> wrote:
> 
>>>The weird register window mechanism from NIOS (is it called NIOS1 now?) 
>>>didn't work well in embedded processing markets.
>>
>>Well, you can hardly call it weird (at least one mainstream arch,
>>SPARC, uses it), and in the embedded space, Tensilica have no problems
>>selling their arch, which also features register windows.
> 
> 
> Just because it is used, doesn't mean its a good idea.  Register
> windows suck.  Register windows reinvented (rotating register file
> from the IA64 suck as well).
> 
> If you want fast function-call save/restore, observe that going into a
> cache or memory, you often have a wide interface, so the cost of
> writing 4 ALIGNED words is the same as writing one, and have aligned 4
> or aligned 8 load/store instructions.  Remember the FPGA mantra: Wires
> are cheap, switching the wires is expensive.
> 
> 
>>If you really want to sling some mud, my favourite part is where they
>>talk about "Avoiding processor obsolescence"... Er, hasn't this has
>>just made NIOS obsolete? How long before they change their minds
>>again?
> 
> 
> Nah, because NIOS1 will still be around.  One of the great things
> about soft-cores is they are a bit easier to keep "in production"
> compared with a hard core.
> 
> 
>>Fair play to them, I didn't really think too much of NIOS, but if they
>>really can push 200MHz with this, then I am impressed.
> 
> 
> Looking at the talk at FPGA on some of the arch tricks used to make
> the ALU so short in NIOS-1, it might be possible.
> 
> 
> 

Article: 69755
Subject: Re: Xilinx V2P: DCM and changing input clock
From: Sean Durkin <smd@despammed.com>
Date: Wed, 19 May 2004 17:21:46 +0200
Links: << >>  << T >>  << A >>
Hi Austin,

Austin Lesea wrote:

> Sean,
> 
> Brute force!
> 
> As long as the locked signal is low, periodically reset the DCM, and see 
> if the locked signal remains low.
> 
> It takes a little state machine, and it would have to run off the DCM 
> CLKIN (which is OK, just assume it is running at 25 MHz to calculate how 
> many counts you need to wait to make sure that LOCKED has gone high).
> 
> Also use the CLKIN_STOPPED bit, and if you use the DFS part of the DCM, 
> use the CLKFX_STOPPED status bit as well (if anything goes wrong, reset 
> the DCM).
OK, that's exactly what I did... I just thought maybe there is some more 
"elegant" way to do this I'm not seeing. But if the pros say that is the 
way to go I'll stick with it. :)

Thanks for the confirmation, Austin!

cu,
Sean

Article: 69756
Subject: Re: Nios II Going Live...
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Wed, 19 May 2004 16:05:06 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <c8fsde$a5q1@cliff.xsj.xilinx.com>,
Austin Lesea  <austin@xilinx.com> wrote:
>All,
>
>If you can compile your code from c, who cares what the architecture is?
>
>Sorry, but it really doesn't matter.
>
>Speed, and ease of use are what counts in this business.
>
>Apologies to processor architects, but unless you are doing a research 
>project, hardly anyone cares anymore about these details.

I disagree on the register window front.  It is a pain if you are
doing garbage collectors (you have to flush the windows), but more
importantly, it DOES impact performance.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 69757
Subject: Re: Antwort: Re: Xilinx WebPack 6 -> Error: 90:Portability <-- anyone can give me a hint?
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 19 May 2004 09:34:27 -0700
Links: << >>  << T >>  << A >>
Ok Klaus,
The first hit was Answer Record # 9936 :-

>>>>>
Problem Description:
Keywords: NgdBuild, error, portability, 90, command, line

Urgency: Standard

General Description:
When running NGDBuild, the following error occurs:

ERROR:Portability:90 - Command line error: Argument "C:\temp\design.edn"
has an invalid extension. The valid extension is ".ngd". If your file name
has more than one "." in it you must explicitly enter the full file name
with
its extension.

Solution 1:


This error is usually the result of having a space in the path leading to
the
macro search directory. For example, if the macro search path was set to:

C:\Program Files\libraries

NGDBuild would issue the above error.

Xilinx tools do not support any white space in directory or file names. To
work around the problem, do not reference any files with spaces in the path.

<<<<<

You read this, right? Just that I see no mention of Impact. So, any white
space in the pathname of your file?

Cheers, Syms.

<khiltrop@gesytec.de> wrote in message
news:c8fs6a$l8h$1@swifty.westend.com...
> Yes, I have been there. If I did not overlook something, there are error
> reports with the same number and keyword, however, from the impact
> programmer.
>
> I have the error with 'translate' process.
>
> Thanks anyway :-)
>
> Klaus,
> Have you been to the Xilinx website answer search thingy? I put
> ERROR:Portability:90 into the search and had four answers appear.
> Somewhere to start.
> Cheers, Syms.



Article: 69758
Subject: Re: Webpack 6.1, ISEexamples, and CoreGen
From: gabor@alacron.com (Gabor Szakacs)
Date: 19 May 2004 10:06:24 -0700
Links: << >>  << T >>  << A >>
"John_H" <johnhandwork@mail.com> wrote in message news:<K3wqc.13$zR5.205@news-west.eli.net>...
> The Coregen tool - in my humble opinion - is generally a dummies guide to
> the Xilinx Library primitives.  I find that instantiating my own memories,
> DCMs and the such are much better done by reading up on the primitives and
> doing a manual instantiation.
> 
> You shouldn't need Coregen - which currently only produces Xilinx-specific
> modules if I recall correctly - to do a proof of concept for the design.
> 
COREgen actually contains some very useful items that are far from
primitives.  I use the FIFO's all the time and they work.  It is a
great way to implement simpler functions, too.  When I work in Schematic
entry I find it saves time over generating simple bus functions by placing
a lot of individual primitives.  Using HDL's this is less useful, but even
then it can be more convenient for things like memories of odd bit widths
that require multiple RAM components or ROM functions when you want to
initialise them from a .coe file.

There are other high level functions like distributed arithmetic FIR filters
that come with the ISE tools, and of course theres all the IP listed on
the Xilinx website under "IP Center" listed as "LogiCORE" or "AllianceCORE"
which require COREgen to customise.

Of course you can make all these functions without COREgen if you like to roll
your own, but in many cases it saves time and effort to use COREgen.

Article: 69759
Subject: Re: IBUFG incapable of driving both CLKDLL and BUFG simultaneously?
From: td@emu.com (Tony Dean)
Date: 19 May 2004 10:07:38 -0700
Links: << >>  << T >>  << A >>
gsm1900user@yahoo.com (GSM User) wrote:
> There is a bug in ISE 6.x. You should manually LOC the IBUFG, BUFGs,
> and DLL. LOC the BUFGP on the same side as input clock and LOC DLL, FB
> BUFG and CLK90 BUFG on the opposite side. Good luck.

> Ray Andraka, P.E. wrote:
> You may have to put LOC constraints on the BUFGs and CLKDLLs.  The automatic placer doesn't do so hot a job figuring out
which BUFGs should be next to which CLKDLLs.  The usual result is that
error message.

> Marc Guardiani <marc@guardiani.com> wrote:
> > Run the input clock to to clock pins. On one, use the CLKDLL. On the 
> > other, use the IBUFG. (You didn't say you needed that other clock pin 
> > for something else :-).
> > 
> > Tony Dean wrote:
> > 
> > > I want my master input clock, which is on a dedicated pin, to clock
> > > most of my logic through a BUFG. I also want it to drive a CLKDLL so I
> > > can use the CLK90 output.
> > > 
> > > After much head-banging I assert the following:
> > > On a Spartan IIE, an IBUFG output cannot be routed to both a CLKDLL
> > > input AND a BUFG input simultaneously.
> > > 
> > > Synplicity will synthesize this setup beautifully, but the Xilinx
> > > Placer won't accept it.
> > > 
> > > 
> > > A double mocha to he or she who can disprove my assertion.
> > > 
> > > -td

Problem solved! While Marc Guardiani deserves Honorable Mention for
his workaround, "GSM User" and Ray Andraka have the correct answer and
are entitled to the double mocha. I had discovered the same fix
shortly before and am pleased to have my findings confirmed. The clue
was in the hitherto-ignored error message:
ERROR:Place:107 - Xilinx requires using locate constraints to preplace
such connected GCLK/GCLKIO/DLL components.
What this actually means apparently, is that Xilinx requires using
locate constraints to preplace such connected GCLK/GCLKIO/DLL
components.
Details for this can be found in the bowels of the Xilinx
documentation at:
http://toolbox.xilinx.com/docsan/xilinx6/books/data/docs/cgd/cgd0128_81.html#wp240140

I'll forward this little tip on to the Xilinx FAE whom I opened a
WebCase with, who apparently is not aware of this detail.

Mochas are payable in person at any cafe here in Santa Cruz. In the
event that transportation costs to and from Santa Cruz exceed the cost
of a double mocha ($3), please supply PayPal address to which said
amount can be promptly remitted.

Thanks to all,
-td

Article: 69760
Subject: Re: Nios II Going Live...
From: kempaj@yahoo.com (Jesse Kempa)
Date: 19 May 2004 10:18:47 -0700
Links: << >>  << T >>  << A >>
Goran Bilski <goran@xilinx.com> wrote in message news:<c8f3f0$cfe1@cliff.xsj.xilinx.com>...
> It seems that Altera has created a MicroBlaze as well.
> They have finally realized that a FPGA based soft processor should have
> - 32 bit ISA
> - 32 registers
> - 3 operand instruction format
> - JTAG based HW debugging
> - HW divider
> 
> The weird register window mechanism from NIOS (is it called NIOS1 now?) 
> didn't work well in embedded processing markets.
> 
> Göran Bilski

Ouch! I don't want to get into any marketing debates or flame wars,
but I feel that inaccurate descriptions of the product I'm familiar
with should be called out:

- Nios I had a 16-bit ISA. You are correct sir.
- Nios I had 32 registers per window (that is, per context), and a
compiler option to make it a flat 32 registers (that has been in the
kit for a couple years now). You are again correct that Nios II has a
flat 32 registers.
- Nios I had JTAG-based HW & SW debugging (for some time now!)
- Nios I had a hardware divider custom instruction (in the kit!) that
in two mouse clicks and a documented compiler switch had HW divides
implemented.

And lest we forget:
- Avalon (off-chip memory at decent performance, anyone?)
- SOPC Builder. 
- A happy user-experience implementing systems.

Regards,

Jesse Kempa
Altera Corp.
jkempa at altera dot com

Article: 69761
Subject: Re: NIOS Board Stratix Edition - FPGA won't configure
From: kempaj@yahoo.com (Jesse Kempa)
Date: 19 May 2004 10:31:50 -0700
Links: << >>  << T >>  << A >>
"Subroto Datta" <sdatta@altera.com> wrote in message news:<n4zqc.524$1O4.119@newssvr15.news.prodigy.com>...
> Vadim, make sure that you have the Unused Pins for your Quartus project set
> to be Inputs Tristated. You can do this as follows after the project is
> opened in Quartus:
> 
> 1. Click on Assign Device
> 2. Click on the Device and Pin Options Button
> 3. Click on the Unused Pins Tab.
> 4. This should be the first Radio button.
> 
> Hope this helps.
> 
> - Subroto Datta
> Altera Corp.


Just to elaborate on why this is:

A feature of the Nios development boards is to demonstrate remote
reconfiguration. This is done via an FPGA I/O which is connected to
the MAX CPLD on the board. The MAX CPLD is programmed to re-configure
the FPGA when the signal is driven low (in this way, the FPGA can send
a signal telling the MAX chip to reconfigure itself). For reference
designs that include this pin and leave it high, or tri-stated, there
is no issue. However, a user design must either drive this pin high
manually, tri-state the pin manually, or leave the pin un-assigned and
tri-state the unused outputs (as Subroto's instructions indicate).

Regards,

Jesse Kempa
Altera Corp.
jkempa at altera dot com

Article: 69762
Subject: Re: Nios II Going Live...
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Wed, 19 May 2004 18:40:26 +0100
Links: << >>  << T >>  << A >>
"Austin Lesea" wrote

> At lunch the other day we were reminiscing about how the Z8000 never
> took off because they changed their architecture and instruction set
> completely from the Z80 and immediately alienated all of their customers
> (who were still programming in assembly language in those days).

Not quite getting it into production may have troubled some customers...

> Not like that anymore.

The Spartan-3 of its day ;-)



Article: 69763
Subject: Re: Video Blob Analysis on FPGAs
From: widding@birger.com (Erik Widding)
Date: 19 May 2004 10:41:04 -0700
Links: << >>  << T >>  << A >>
"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote...
> I have done some armchair thinking about how to keep and
> combine blobs if they should merge in susbsequent lines.
> This may be done by keeping start and stop points of the
> various blobs in a RAM LUT.  But maybe this isn't the
> best approach?

We identified the option that you described, and a second approach 
that involved keeping track of an ID for each blob that was in 
process and storing with each pixel in a line the blob ID that the 
pixel corresponded to.  We did this as we had to be able to both 
fill the voids in blobs to get an accurate centroid of the entire 
blob, and also find an accurate mass and centroid for the voids in
the blobs as well.  We are basically looking for black circular 
blobs, that contain six white circular voids of varying mass.  By 
decoding the locations of the voids, we identify one of 729 
possible marks.  This is used for localization of a robot, as an 
interim step to scene based localization.

> I saw mention of run length encoding in a web page by
> Wintress.  I do not know what advantage that encoding has
> over a fifo that would give you the pixel threshold on every
> pixel clock.  I do know that some camera manufacturers like
> Basler make cameras that threshold and run length encode
> their outputs presumably to cut down on cable bandwidth.

Exactly.  In some vision applications, very few features need to be 
found, and this can drastically reduce the bandwidth.

> I am not sure what you mean by the term non-convex.  To
> a newbie that is concave but you don't use the word concave
> so perhaps this has a different meaning.

The term evolved from the notion that blobs are inherently convex.  
A non-convex blob has a concave feature somewhere on its boundary.  

> I have also come across 4 neighbor or 8 neighbor terminology
> which I assume represent the rules for making a connection,
> based on a tic-tac-toe arrangement of pixels.  I would suppose
> that the 8 neighbor approach would be a tad more robust but
> may lead to narrowly connected blobs with only a point in
> common.  Whis is better?

Which mode of connection you choose is entirely application 
dependent.  Four-connected blobs are sufficient for convex objects, 
eight-connected are more important if the feature size to pixel 
size ratio is quite small.

> On my web searching I have tried to refine my search to
> just source code by using unique VHDL keywords like
> downto and inout.  However I didn't find anything with
> this search: downto inout blob.  Any suggestions to
> better search techniques or Verilog keywords will
> be appreciated.

I do not suspect you will find any source code, but please don't use 
my skepticism as a reason not to look.

> Another roboticist. Thanks so much.
> Do you want to share with the group what Birger does?

Actually, our involvement with robotics has been limited to the 
development of a vision system for a robot.  Birger is primarily 
involved in the development of vision and compression algorithms on 
FPGAs.  The vision system that we have devloped has the following 
characteristics: 
   PC/104+ form
   Xilinx XC2VP20-FG676 FPGA (up to a XC2VP40 will fit)
   64MB DDR SDRAM (32 bit datapath)
   Xilinx SystemAceCF
   VGA LCD interface w/HV inverter for backlight
   Stereo Audio CODEC
   Nine VGA camera inputs (one color, eight mono)
   MJPEG compression, and color converion for color camera
   Stereo disparity search on four QVGA camera pairs

Features that we are currently working on:
   Dewarp - 8 x VGA input, 8 x QVGA output
   Blobfinder/FiducialFinder
   MJPEG decompression

Everything runs at 15FPS.  Many of the engines run at 30+FPS.  Due 
to power considerations, we developed the VGA cameras from scratch, 
which burn approximately 200mW each, and are approximately 20mm on a 
side.  Is this hardware/IP that other robotcs developers would find 
useful?  This has been developed for a government agency, and we are
investigating how we might productize it.


Regards,
Erik Widding.

Birger Engineering, Inc. -------------------------------- 617.695.9233
100 Boylston St #1070; Boston, MA 02116 -------- http://www.birger.com

Article: 69764
Subject: Re: How to replace Triscend - Xilinx plans for the future
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 19 May 2004 14:09:00 -0400
Links: << >>  << T >>  << A >>
Jim Granville wrote:
> 
> Jim Granville wrote:
> <snip>
> >  There are a LOT of Arm cores comming as MCU, with on chip FLASH, and
> > that solves the smaller-memory end, by removing the memory BUS layout
> > problems.
> >
> >  Look at Philips LPC2xxx, STm STR7xxx, Analog Devices ADuC7xxx, TIs
> > TMS470, Sony, etc for FLASH+ARM offerings, many with external memory
> > interfaces.
> 
> .. I should have included Motorola's MAC7100 ARM devices, TQFP144,
> 512KF, 32KR, Automotive specs..

Wow!  This is a part I have been looking for for quite sometime.  I
don't see any info on pricing or availability... any idea?  I have sent
an email to Arrow, we'll see what they say.  

It does not look like this part will interface directly to SDRAM... too
bad, that is the only lacking feature for my app, but I can live without
it.    

-- 

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: 69765
Subject: Chipscope with clock enable.
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 19 May 2004 11:12:09 -0700
Links: << >>  << T >>  << A >>
Hi,
I'm trying to use Chipscope with a Virtex-e design. Problem is that my
design runs with a very fast clock (>170 MHz) which is clock enabled.
Chipscope needs a measurement clock and I wondered if it supports a clock
enable? It can't run at the full clock rate. I couldn't find that option, so
I guess I'll need to make a special clock for it.
TIA, Syms.



Article: 69766
Subject: Re: Atmel Zigbee solutions
From: "Ulf Samuelsson" <ulf@atmel.nospam.com>
Date: Wed, 19 May 2004 20:15:33 +0200
Links: << >>  << T >>  << A >>
 >   Zigbee news from Atmel - what's key here, is a move from generic
> uC/Chip sales, into also selling the Zigbee SW stack, so users have
> minimal SW developments for their links.

Nope, no move, just another group within using the AVR for a good purpose.
The AT86RF401 is the same story.
The AT76C711 AVR has been around for some time using the same concept.
The follow on device AT76C712 is moving into the general purpose
domain, and will be sold to both Fred in the Shed and Joe Sixpack.
Nice 48 MHz AVR with USB and UARTs.

>   This will be key to their AVR sales, very like CypressMicrosystems
> promote their PsOC - they include Sw support flows, so customers
> need less skills.
>
> http://www.atmel.com/dyn/corporate/view_detail.asp?FileName=Zigbee.html
>
> http://www.atmel.com/dyn/resources/prod_documents/5056S.pdf
>
> $6.75/100K for a chipset is not super-cheap, but from a NZ standpoint,
> the Zigbee solution is probably better than Bluetooth.

Each has their own uses...
Europe fought for 30 years to determine which should prevail:

                Catolicism  *OR*  Protestantism.

Guess what ....


>   Zigbee is slower, but gives more range, and suits Alarms, Security,
> Wireless Logging and similar near-field applications.
>
>   Would likely also make a great marine-instrumentation link on boats,
> for non-graphical interfaces.
>
> -jg
>



-- 
Best Regards,
Ulf Samuelsson   ulf@a-t-m-e-l.com
This is a personal view which may or may not be
share by my Employer Atmel Nordic AB




Article: 69767
Subject: Re: How to replace Triscend - Xilinx plans for the future
From: "Ulf Samuelsson" <ulf@atmel.nospam.com>
Date: Wed, 19 May 2004 20:29:28 +0200
Links: << >>  << T >>  << A >>

"Anders" <ankoe@EMAIL-Protected.se> skrev i meddelandet
news:97810a59e9658cd3b6f25f198eb9cd14@localhost.talkaboutelectronicequipment.com...
> Two months after Xilinx acquired Triscend, it now seems they are planning
> to kill the Triscend products. We recently got the End-of-life
> notification for the A7 processor, and I guess the E5 is also going.
>
> Does anybody know of a replacement for the Triscend A7 processor? We are
> using it together with a Xilinx FPGA (at least until now...) and have
> implemented a FIFO in the CSL to move data at high speed from the FPGA to
> external SDRAM (Up to 128 Mbits/second in packets of 8 32-bit words). This
> link seems to be difficult to implement using a "standard" ARM7
> processor.
>
> Any suggestions and views are appreciated.
>
> /Anders
>


If you use a controller like the AT91R40008 with 256 kB internal SRAM
and implement the SDRAM controller in the FPGA it is a piece of cake.
CPU runs at 60 MIPS, no sweat when executing out of internal SRAM.
You can make a lot of transfers per microsecond...
Use the FIQ interrupt into the ARM7 to get maximum throughput.

The FPGA can implement its own DMA controller.
Alternatively the ARM7 can do a move multiple from internal SRAM
to the DRAM at a "high" address, using a special chip select signal
When the FPGA sees this chipselect active, it can ignore data
coming in over the CPU bus and take it from a FIFO in the FPGA.
 128 Mbit / second is 8 x 16 words so you need to do 8 x 16 bit transfers
per microsecond.

If you dont want to worry about SDRAM controllers, use PseudoRAM
(DRAM with an SRAM interface).
Maybe implement a page mode feature in the FPGA.

Hopes this helps
Since you seem to be based in Sweden, you can contact me directly.
If you have any decent volume, we have better solutions.

-- 
Best Regards,
Ulf Samuelsson   ulf@a-t-m-e-l.com
This is a personal view which may or may not be
share by my Employer Atmel Nordic AB



Article: 69768
Subject: Re: Nios II Going Live...
From: petersommerfeld@hotmail.com (Peter Sommerfeld)
Date: 19 May 2004 11:43:27 -0700
Links: << >>  << T >>  << A >>
Why do you think it's wierd? I found the fast ISR entrance quite
useful. I hope ISR entrance is as fast in Nios II. I heard it the
windowing was thrown out because of patent issues, not on its
technical merits.

-- Pete

> 
> The weird register window mechanism from NIOS (is it called NIOS1 now?) 
> didn't work well in embedded processing markets.
> 
> Göran Bilski
> 
> 
> Kenneth Land wrote:
> 
> >Tomorrow is the big Nios II launch date, but info is already going up....
> >
> >www.altera.com
> >
> >http://www.fpgajournal.com/articles/20040518_nios2.htm
> >
> >
> >Full 32bit. 2X-4X faster than Nios I and starts at only 500 LE's.  New IDE.
> >New Compact Flash and other periferals.... Can't wait to get a hold of it.
> >
> >Ken
> >
> >
> >  
> >

Article: 69769
Subject: Re: Malfunctioning dual port block ram.
From: jon@beniston.com (Jon Beniston)
Date: 19 May 2004 11:54:58 -0700
Links: << >>  << T >>  << A >>
> > Possibly not the same problem, but I've seen issues recently with a
> > Core Gen RAM not being synthed properly by XST. I switched over to
> > Synplify and the problem disappeared.. My faith in XST is limited!
> > 
> 
> I didn't think that Coregen'ed stuff *was* synthesised - does the
> synth not see it as a black box? Then the downstream tools find the
> EDIF netlist to fill in the gap..

Could it wire up the black box wrong? Functional sim worked okay and
post-translate sim didn't (neither did h/w). It could have been the
translate prog that screwed up I guess, but I didn't have the time or
will to find out. Whenever things like that have happened before,
switching to Synplify always fixed it.
 
Cheers,
JonB

Article: 69770
Subject: Re: Nios II Going Live...
From: Goran Bilski <goran@xilinx.com>
Date: Wed, 19 May 2004 20:57:05 +0200
Links: << >>  << T >>  << A >>
It's creating weird situation in embedding processing where you reach 
the limit of the window.
There should only be different 3 numbers used as sizes, 0, 1 or infinity.
Any other number will creating barriers that will be reach and have 
impacts on the system.
On reaching the limit of the register window, you have a big chunk of 
data to save and load which isn't nice to have when you need to have a 
deterministic system.

Göran

Peter Sommerfeld wrote:

>Why do you think it's wierd? I found the fast ISR entrance quite
>useful. I hope ISR entrance is as fast in Nios II. I heard it the
>windowing was thrown out because of patent issues, not on its
>technical merits.
>
>-- Pete
>
>  
>
>>The weird register window mechanism from NIOS (is it called NIOS1 now?) 
>>didn't work well in embedded processing markets.
>>
>>Göran Bilski
>>
>>
>>Kenneth Land wrote:
>>
>>    
>>
>>>Tomorrow is the big Nios II launch date, but info is already going up....
>>>
>>>www.altera.com
>>>
>>>http://www.fpgajournal.com/articles/20040518_nios2.htm
>>>
>>>
>>>Full 32bit. 2X-4X faster than Nios I and starts at only 500 LE's.  New IDE.
>>>New Compact Flash and other periferals.... Can't wait to get a hold of it.
>>>
>>>Ken
>>>
>>>
>>> 
>>>
>>>      
>>>


Article: 69771
Subject: Re: Initialize Blockram from file
From: gabor@alacron.com (Gabor Szakacs)
Date: 19 May 2004 12:11:43 -0700
Links: << >>  << T >>  << A >>
I think you're looking for a way to initialize the RAM after
the FPGA is placed and routed so you don't need to recompile?
If you use the .ucf file to initialize the RAM it will require
re-running place-and-route.
There is an article on merging RAM data directly into the bitstream
file in the TechXclusives section of Xilinx.com titled
"Reconfiguring Block RAMs" by Kris Chaplin

jon@beniston.com (Jon Beniston) wrote in message news:<e87b9ce8.0405190626.2c08ec5@posting.google.com>...
> Daniel Köthe <d.koethespam@colour-control.com> wrote in message news:<c8f1te$9ir$1@news.eastlink.de>...
> > Hello,
> > i think in the last release of Xilinx Webpack 6.1 or 6.2 the abilitiy 
> > has added to initialize a blockram from file by xst. But this feature is 
> > not documented by xilinx or 1 don't found it.
> > 
> > Has anyone used this feature?
> 
> You can certainly do it using Core Gen. Also, if you look under
> language templates in Project Navigator, you can do it with defparams:
> 
>    // RAMB16_S1: Virtex-II/II-Pro, Spartan-3 16kx1 Single-Port RAM
>    // Xilinx  HDL Language Template version 6.1i
> 
>    RAMB16_S1 RAMB16_S1_inst (
>       .DO(DO),      // 1-bit Data Output
>       .ADDR(ADDR),  // 14-bit Address Input
>       .CLK(CLK),    // Clock
>       .DI(DI),      // 1-bit Data Input
>       .EN(EN),      // RAM Enable Input
>       .SSR(SSR),    // Synchronous Set/Reset Input
>       .WE(WE)       // Write Enable Input
>    );
> 
>    // The following defparam declarations are only necessary if you
> wish to change the default behavior
>    // of the RAM. If the instance name is changed, these defparams
> need to be updated accordingly.
> 
>    defparam RAMB16_S1_inst.INIT = 1'h0;  // Value of output RAM
> registers at startup
>    defparam RAMB16_S1_inst.SRVAL = 1'h0; // Ouput value upon SSR
> assertion
>    defparam RAMB16_S1_inst.WRITE_MODE = "WRITE_FIRST"; // WRITE_FIRST,
> READ_FIRST or NO_CHANGE
> 
>    // The following defparam INIT_xx declarations are only necessary
> if you wish to change the initial
>    // contents of the RAM to anything other than all zero's.
> 
>    defparam RAMB16_S1_inst.INIT_00 =
> 256'h0000000000000000000000000000000000000000000000000000000000000000;
>  
> Cheers,
> JonB

Article: 69772
Subject: Re: Nios II Going Live...
From: "Kenneth Land" <kland1@neuralog1.com1>
Date: Wed, 19 May 2004 14:27:31 -0500
Links: << >>  << T >>  << A >>

"Goran Bilski" <goran@xilinx.com> wrote in message
news:c8gaoj$cfb1@cliff.xsj.xilinx.com...
> It's creating weird situation in embedding processing where you reach
> the limit of the window.
> There should only be different 3 numbers used as sizes, 0, 1 or infinity.
> Any other number will creating barriers that will be reach and have
> impacts on the system.
> On reaching the limit of the register window, you have a big chunk of
> data to save and load which isn't nice to have when you need to have a
> deterministic system.
>
> Göran
>

Can you explain a bit more?  If you need more than 31 levels of call stack,
how deterministic could your application be?

I know there is merit to what you say, as that's why NiosI has the mflat
model available.  I'd just like to have it explained.

Ken



Article: 69773
Subject: Re: Initialize Blockram from file
From: Shalin Sheth <Shalin.Sheth@xilinx.com>
Date: Wed, 19 May 2004 12:38:09 -0700
Links: << >>  << T >>  << A >>
You can initialize BlockRAM after the bitfile has been created using a 
tools called Data2MEM that is part of the Xilinx ISE tools.  To read 
more about Data2MEM goto:
http://www.xilinx.com/ise/embedded/data2bram.htm

Shalin-

Gabor Szakacs wrote:
> I think you're looking for a way to initialize the RAM after
> the FPGA is placed and routed so you don't need to recompile?
> If you use the .ucf file to initialize the RAM it will require
> re-running place-and-route.
> There is an article on merging RAM data directly into the bitstream
> file in the TechXclusives section of Xilinx.com titled
> "Reconfiguring Block RAMs" by Kris Chaplin
> 
> jon@beniston.com (Jon Beniston) wrote in message news:<e87b9ce8.0405190626.2c08ec5@posting.google.com>...
> 
>>Daniel Köthe <d.koethespam@colour-control.com> wrote in message news:<c8f1te$9ir$1@news.eastlink.de>...
>>
>>>Hello,
>>>i think in the last release of Xilinx Webpack 6.1 or 6.2 the abilitiy 
>>>has added to initialize a blockram from file by xst. But this feature is 
>>>not documented by xilinx or 1 don't found it.
>>>
>>>Has anyone used this feature?
>>
>>You can certainly do it using Core Gen. Also, if you look under
>>language templates in Project Navigator, you can do it with defparams:
>>
>>   // RAMB16_S1: Virtex-II/II-Pro, Spartan-3 16kx1 Single-Port RAM
>>   // Xilinx  HDL Language Template version 6.1i
>>
>>   RAMB16_S1 RAMB16_S1_inst (
>>      .DO(DO),      // 1-bit Data Output
>>      .ADDR(ADDR),  // 14-bit Address Input
>>      .CLK(CLK),    // Clock
>>      .DI(DI),      // 1-bit Data Input
>>      .EN(EN),      // RAM Enable Input
>>      .SSR(SSR),    // Synchronous Set/Reset Input
>>      .WE(WE)       // Write Enable Input
>>   );
>>
>>   // The following defparam declarations are only necessary if you
>>wish to change the default behavior
>>   // of the RAM. If the instance name is changed, these defparams
>>need to be updated accordingly.
>>
>>   defparam RAMB16_S1_inst.INIT = 1'h0;  // Value of output RAM
>>registers at startup
>>   defparam RAMB16_S1_inst.SRVAL = 1'h0; // Ouput value upon SSR
>>assertion
>>   defparam RAMB16_S1_inst.WRITE_MODE = "WRITE_FIRST"; // WRITE_FIRST,
>>READ_FIRST or NO_CHANGE
>>
>>   // The following defparam INIT_xx declarations are only necessary
>>if you wish to change the initial
>>   // contents of the RAM to anything other than all zero's.
>>
>>   defparam RAMB16_S1_inst.INIT_00 =
>>256'h0000000000000000000000000000000000000000000000000000000000000000;
>> 
>>Cheers,
>>JonB


Article: 69774
Subject: Re: program flash memory through JTAG on FPGA
From: "E.S." <emu@ecubics.com>
Date: Wed, 19 May 2004 13:45:31 -0600
Links: << >>  << T >>  << A >>
Eric Crabill wrote:

> Hi,
> 
> There's a tool called Universal Scan that does just what
> you are looking for.  http://www.universalscan.com/
> I had some students using it at SJSU to program an Intel
> Flash attached to a Spartan-IIE.  I was impressed with 
> the tool.

In the last issue of Xcell-Journal (49) there is an article
about it. They call it "inexpensive" ;-)





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