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 100375

Article: 100375
Subject: Re: what is architectural diffrence between block ram & distributed
From: John_H <johnhandwork@mail.com>
Date: Fri, 07 Apr 2006 13:20:35 GMT
Links: << >>  << T >>  << A >>
kulkarku@math.net wrote:
> what is architectural diffrence between block ram & distributed ram?

BlockRAM is a dedicated bloack of memory, each either 4 kbit or 18 kbit 
in size debending on the Xilinx device.  Distributed "CLB SelectRAM" 
memory is implemented in the look-up tables in the FPGA logic fabric. 
The data sheet gives a clear explanation of both.

Happy reading!

Article: 100376
Subject: Re: Accessing compact flash?????????
From: Eli Hughes <emh203@psu.edu>
Date: Fri, 07 Apr 2006 09:25:33 -0400
Links: << >>  << T >>  << A >>
sachink321@gmail.com wrote:
> Environment in which system works:
> 
> Microblaze softcore processor on spartan 3 fpga board
> compact flash, acting as a mass storage.
> 
> How to access the compact flash in embedded applications
> write to and read from the compact flash? how to access the FAT table?
> to which sector i need to write, which address?
> 
> which mode of addressing is easy way out
> CHS  or LBA??
> 
> I got no clue how to access, it would be great help if i could
> understand in and out of doing tht becoz i need to write a code in C
> 
> Thanks in advance
> 


If you use the SYSTEM Ace controller chip , you can easily get to FAT 
file system access!  There is actually a nice piece of IP that comes 
with the EDk that gives you basic file access.


-ELi


Article: 100377
Subject: Re: USB Interface to Virtex-4
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 07 Apr 2006 06:33:17 -0700
Links: << >>  << T >>  << A >>
Jim,

Agreed.  If you have to have a substantial core of soft logic to support 
that interface in the FPGA, it had better be worth it.  If the FPGA has 
hardened cores for most, or part of that interface, it makes it a 
slightly better proposition.

It is all systems engineering.

I admit that when I sit down to do that job (very rarely now), I pick 
the components that will:

- do the best job
- cause me the least grief (both in software/coding and signal 
integrity/support)
- meet the cost objectives

When all the marketing hype is said and done, the hard work is just 
begun for the engineer.

Successful completion and testing of the prototype is an important step.

And then manufacturing can be another real trial.

So it ain't over till the customer is paying (and happy).

Anything that gets you to market faster is a real plus.  The systems 
engineer can make, or break a project by their decisions.

Austin

Jim Granville wrote:

> Austin Lesea wrote:
> 
>> All,
>>
>> When we recently did a USB interface to the FPGA, we looked at the USB 
>> interface parts that were out there, their features, and their costs.
>>
>> We decided on a complete module (connector, and all) just because it 
>> was  - 1.  incredibly cheap, 2.  useful (it has its own 8 bit uP to 
>> take care of everything we would ever need), and 3. it is done, and 
>> working (one less thing to do).
>>
>> Tightly integrating the USB into the FPGA has about 0 benefit.  It is 
>> not like having an ethernet port, or a 6.25 Gbs serial link, or PCI 
>> express, or any of a number of high bandwidth interfaces where tight 
>> coupling just makes sense.
> 
> 
> True, tho I'd say that Ethernet is moving into the same category as
> you have placed USB. Not GBit ethernet, but certainly vanilla 10/100,
> where there are smarter/cheaper PHY included options to choose from.
> 
> -jg
> 
> 

Article: 100378
Subject: Re: rather simple gsr Q
From: "Roger Bourne" <rover8898@hotmail.com>
Date: 7 Apr 2006 06:47:20 -0700
Links: << >>  << T >>  << A >>

Roger Bourne wrote:
> Errrr...
>
> When I typed the previous post, I did not have access to the project
> navigator software...
> So...
>
> > I had tried that before but I was confused as the STARTUP_SPARTAN3
> > module had both GSRin and GSRout pins. I had assumed that the module
> > was only for simulation purposes.
> > ( At least I think it was the  STARTUP_SPARTAN3 module. There were only
> > 2 modules that had began with the wotd "startup", and I had tried them
> > both. They were identical.)
>
> Today, (that I have access to the projects navigator software) I took a
> closer look at both modules that began with the word "startup". I
> realized that both modules are in fact NOT the same. I was able to
> locate the 3 pin STARTUP_SPARTAN3 module. ( I was previously selecting
> the STARBUF_SPARTAN3 module. Spelling is too similar).
>
> Thank you for your help.
> -Roger

Hmmm...

When I inserted the STARTUP_SPARTAN3 module in the top level schematic,
and connected it's GSR pin to the top level schematic's GSR net, I
obtained the following message:

Warning:DesignEntry - toplevel_schem.sch: Net 'GSR' is connected to
load pins and/or I/O markers, but not connected to any source pin or
I/O marker.
Totally, 1 error(s) and warning(s) are detected

It seems that the STARTUP_SPARTAN3 module cannot drive its GSR pin. Is
its GSR pin an input or an output ?
Are there any options I need to set?

Please advise
-Roger


Article: 100379
Subject: Re: USB Interface to Virtex-4
From: "Anonymous" <someone@microsoft.com>
Date: Fri, 07 Apr 2006 13:54:32 GMT
Links: << >>  << T >>  << A >>

"Anonymous" <someone@microsoft.com> wrote in message
news:NvfZf.78923$%84.17918@tornado.southeast.rr.com...
>
> "Felix Bertram" <flx@bertram-family.com> wrote in message
> news:49l64gFp3eu7U1@individual.net...
> > > I agree the software is complicated. (Way too complicated in my
> opinion.)
> >
> > if "software" is referring to the firmware: this is really not too
> > complicated. Have a look here:
> > * www.usb-by-example.com
> > * www.lvr.com
> >
> > > But all the solutions out there seem to be built around a little 8-bit
> > > micro. You don't think it's silly to have a 10 million gate FPGA
sitting
> > > next to an 8051?
> >
> > disagreed. There are two types of data to be very clearly separated:
> >
> > * asynchronous data: this is all the USB device enumeration and control
> > stuff. This is low bandwidth, most of it happens only during device
> > attachment, and this is quite simple. An 8051 is still too complex to
> > handle this, there are designs out there using a simple state machine.
> >
> > * isochronous data: this is all the traffic your application requires.
> > In case you are streaming high bandwidth data and you need to do some
> > processing on it, an FPGA might be a good solution. You will usually not
> > want to pass 480Mbps of data through a CPU. Think of audio or video
> > applications, USB protocol analyzers, ...
> >
> >
> > Any comments welcome,
> > best regards,
> >
> >
> > Felix
> > -- 
> > Dipl.-Ing. Felix Bertram
> > http://www.bertram-family.com/felix
>
> I guess my point was if you look at an fx2, for example, all I see is an
> 8-bit micro, a little bit of memory, and some relatively simple fifo
> hardware. All of this seems trivial inside a virtex-4, yet most v4 designs
> I've seen have the usb outside the fpga. Maybe that's so they can load the
> fpga at power up but it seems like if they have flash memory anyway,
there's
> no real advantage to usb outside the fpga.
>
> -Clark
>
>

I have to admit that I find some of the replies to what I thought was a dumb
question a little odd. It's almost like some folks take personal offense at
the notion of using a couple hundred slices and a couple block rams to
implement a USB interface inside the FPGA. (The smallest V4fx has 12,000 lcs
and 36 brams) I think most of the counterarguments could apply to any other
peripheral: Why a uart? Why ethernet? Why even a PPC core when you can get a
better processor discretely?

If I had a solution that:
1. Integrated into EDK such that it adds like any other peripheral. The IP
should contain the micro, firmware, and the interface to the CPU.
2. Integrated into the board support package so that I can build my chip,
carry a few files over to my linux source and be able to compile it into the
linux kernel.
3. Stock linux and windows driver support.
4. Netusb compatibility such that I can take my usb master port and connect
it to any other port to create a network link.
5. USB1.1 initially but eventually 2.0.

I would gladly use it over any discrete solution that I constantly have to
worry about obscolecense or other supply problems, not to mention the extra
size, cost(part plus ordering plus handling), and power. Who hasn't had a
board build delayed because of a back order on some small part like a usb
chip?

-Clark





Article: 100380
Subject: Re: Accessing compact flash?????????
From: Jan Panteltje <pNaonStpealmtje@yahoo.com>
Date: Fri, 07 Apr 2006 14:21:34 GMT
Links: << >>  << T >>  << A >>
On a sunny day (Fri, 07 Apr 2006 09:25:33 -0400) it happened Eli Hughes
<emh203@psu.edu> wrote in <e15p8e$1hji$1@f04n12.cac.psu.edu>:

>sachink321@gmail.com wrote:
>> Environment in which system works:
>> 
>> Microblaze softcore processor on spartan 3 fpga board
>> compact flash, acting as a mass storage.
>> 
>> How to access the compact flash in embedded applications
>> write to and read from the compact flash? how to access the FAT table?
>> to which sector i need to write, which address?
>> 
>> which mode of addressing is easy way out
>> CHS  or LBA??
>> 
>> I got no clue how to access, it would be great help if i could
>> understand in and out of doing tht becoz i need to write a code in C
>> 
>> Thanks in advance
>> 
>
>
>If you use the SYSTEM Ace controller chip , you can easily get to FAT 
>file system access!  There is actually a nice piece of IP that comes 
>with the EDk that gives you basic file access.

I dunno, but 100 years ago or so when I moved from CP/M to MSDOS
I hacked together a simple file transfer function in C.
It is 'clean room', but then I did have MS floppies to test.
ftp://panteltje.com/pub/ms_fat.bz2

Not even sure that will work with current FAT, have to try some day.
But it has some test routines....
At the center of it it has a routine rwsabs()

rwsabs(sabs,dma,rwf) /*read or write sector abs*/
int sabs;/*absolute sector, starting at 0*/
unsigned dma; // memory address

Could be informative perhaps, ignore the sys14 routine calls.
Now to hope the richest man in the world does not sue me :-)



Article: 100381
Subject: Re: USB Interface to Virtex-4
From: "Marc Reinig" <nospam@nospam.com>
Date: Fri, 07 Apr 2006 14:26:56 GMT
Links: << >>  << T >>  << A >>
>> I guess my point was if you look at an fx2, for example, all I see is an
>> 8-bit micro, a little bit of memory, and some relatively simple fifo
>> hardware.

That's because you are looking at a very simplified block diagram.  The 
logic is a bit more complicated.

> I would gladly use it over any discrete solution that I constantly have to
> worry about obscolecense or other supply problems, not to mention the 
> extra
> size, cost(part plus ordering plus handling), and power. Who hasn't had a
> board build delayed because of a back order on some small part like a usb
> chip?

You would still need an external USB PHY no matter what and they are even 
more prone to supply issues because of the limited demand/volume of 
production.

Marc Reinig
System Solutions



Article: 100382
Subject: Re: Virtex-4 RocketIO and G.709 OTU-2
From: Gerhard Hoffmann <dk4xp@freenet.de>
Date: Fri, 07 Apr 2006 16:50:08 +0200
Links: << >>  << T >>  << A >>
On Wed, 22 Mar 2006 12:00:26 +1100, Allan Herriman <allanherriman@hotmail.com> wrote:

>On 21 Mar 2006 09:08:21 -0800, "Alain" <no_spa2005@yahoo.fr> wrote:
>
>>Unfortunately, even OC-192 is excluded form Virtex- 4 (ug076.pdf :
>>"Payload compatible only"), so no hope for OTU-2 I think.
>>We have to wait Virtex-5 family ?
>
>No.  That is unlikely to have sufficient jitter performance, due to
>certain compromises that must be made when putting an MGT on an FPGA.
>In particular, it's likely to use a ring oscillator rather than an LC
>oscillator which would have better perfomance.

Is jitter the only limitation? Most fiber optic transceivers (XFP & friends)
have eye openers of their own and resynchronize everything anyway.

regards, Gerhard



Article: 100383
Subject: Re: LVDS in Spartan-3E
From: "John_H" <johnhandwork@mail.com>
Date: Fri, 07 Apr 2006 15:50:04 GMT
Links: << >>  << T >>  << A >>
"Steve Knapp (Xilinx Spartan-3 Generation FPGAs)" <steve.knapp@xilinx.com> 
wrote in message 
news:1144366043.186825.39990@e56g2000cwe.googlegroups.com...
> John_H wrote:
<snip>
>> Oops.

>> I just remembered - there are only 4 banks on the Spartan3E.  Yikes!
>> The pairs per bank are 1.4x-2x the Spartan3 values so it looks like they
>> may be legit.

>> I sure hope those SSOs get changed!!!

> Which package did you plan to use and how many LVDS output pairs are
> required?  The different SSO numbers on the quad-flat packages are
> purposely lower due to their merely average signal integrity.  The BGA
> packages have superior signal integrity.
>
> Here's how you would calculate the recommended limit using the data
> sheet values.
> http://www.xilinx.com/bvdocs/publications/ds312.pdf
>
> Let's assume that you're using the TQ144 package, which has the
> equivalent of 2 VCC/GND pairs per bank (Table 92, page 133).  Then, go
> to the LVDS_25 section in Table 93 (on page 134), indicating that you
> can have 4 LVDS  _output pairs_ (emphasis included) per power ground
> pair.  Multiply the values together to arrive at 8 LVDS _output pairs_
> on a bank in the TQ144 package.  Again, the SSOs are a recommendation,
> but let's keep it to 8 pairs, which equations to 16 I/O pins.  There
> are only ~23 I/O on a package edge in the TQ144.  The Input-only pins
> are not available as outputs.  Also, SSOs are only for outputs.  You
> can have as many LVDS inputs that will fit in an I/O bank.
<signature snip>

Thanks for the info, Steve.  The only time I've had real troubles in the 
past was getting a feel-good for the improperly specified number of PCI 
signals per bank for the PQFP.  The data sheet does a good job of presenting 
the SSO information (which isn't seen so clearly in competitors' 
literature).

For my current design I was looking at an LVDS translator on the front end 
implemented in a separate FPGA.  The VQ or TQ package would make sense for 
such a low pin count application - 4 pairs in, 11 pairs out - but the SSO 
limits would exclude a simple flow-through design.  In the VQ or TQ package 
I couldn't put all 11 balanced-current LVDS drivers on one bank.

The design will end up using Xilinx after all and a BGA package for the 
front end and the main functionality removes most of the limits.

PCI interfaces are something we've implemented a bunch in the past.  The SSO 
numbers for the Spartan3E in the wireframe packages spread the interface out 
over at least 3 banks if those SSOs are to be believed.  That's a bit more 
of a restriction than I'd expect but they are just wireframe packages.  I'm 
hoping we're at the point soon where the price for wireframes aren't as 
attractive when compared to the "better" packaging.

- John_H 



Article: 100384
Subject: Infer dual-clock block RAM for Xilinx
From: "Amal" <akhailtash@gmail.com>
Date: 7 Apr 2006 08:50:31 -0700
Links: << >>  << T >>  << A >>
Anyone has code templates for infering a dual-port, dual-clock, block
RAM (RAMB16) for Xilinix using Synplicity and VHDL?

Xilinx XST supports this using shared variable for memory and two
processes for each write port.  But I can't seem to find anything for
Synplicity.

-- Amal


Article: 100385
Subject: Re: Infer dual-clock block RAM for Xilinx
From: "John_H" <johnhandwork@mail.com>
Date: Fri, 07 Apr 2006 15:55:38 GMT
Links: << >>  << T >>  << A >>
Have you tried to infer it yourself?  It's something that's easy to do with 
Synplicity's tools in Verilog, I imagine they do as good a job with VHDL. 
You have an array, a write, and a read.  You have your choice of a 
registered read from a combinatorial address or an asynchronous read from a 
registered address (which they translate back to the former, native 
arrangement).  They do a great job of taking care of the other control 
signals as well.

The Synplify(Pro) online manual should also give you some guidance or at 
least a description of what they expect to provide for support.


"Amal" <akhailtash@gmail.com> wrote in message 
news:1144425031.848581.165630@z34g2000cwc.googlegroups.com...
> Anyone has code templates for infering a dual-port, dual-clock, block
> RAM (RAMB16) for Xilinix using Synplicity and VHDL?
>
> Xilinx XST supports this using shared variable for memory and two
> processes for each write port.  But I can't seem to find anything for
> Synplicity.
>
> -- Amal 



Article: 100386
Subject: Re: Infer dual-clock block RAM for Xilinx
From: "Symon" <symon_brewer@hotmail.com>
Date: Fri, 7 Apr 2006 17:03:09 +0100
Links: << >>  << T >>  << A >>
Amal,
I guess your Google access is broken? ;-)
http://www.synplicity.com/literature/pdf/inferring_blockRAMs.pdf
Cheers, Syms.

"Amal" <akhailtash@gmail.com> wrote in message 
news:1144425031.848581.165630@z34g2000cwc.googlegroups.com...
> Anyone has code templates for infering a dual-port, dual-clock, block
> RAM (RAMB16) for Xilinix using Synplicity and VHDL?
>
> Xilinx XST supports this using shared variable for memory and two
> processes for each write port.  But I can't seem to find anything for
> Synplicity.
>
> -- Amal
> 



Article: 100387
Subject: Re: rather simple gsr Q
From: "Steve Knapp (Xilinx Spartan-3 Generation FPGAs)" <steve.knapp@xilinx.com>
Date: 7 Apr 2006 09:21:39 -0700
Links: << >>  << T >>  << A >>
Roger Bourne wrote:
> Roger Bourne wrote:
[ ... snip ...]

> When I inserted the STARTUP_SPARTAN3 module in the top level schematic,
> and connected it's GSR pin to the top level schematic's GSR net, I
> obtained the following message:
>
> Warning:DesignEntry - toplevel_schem.sch: Net 'GSR' is connected to
> load pins and/or I/O markers, but not connected to any source pin or
> I/O marker.
> Totally, 1 error(s) and warning(s) are detected
>
> It seems that the STARTUP_SPARTAN3 module cannot drive its GSR pin. Is
> its GSR pin an input or an output ?
> Are there any options I need to set?

I believe the software is attempting to tell you that the GSR signal
has one or more loads connected (likely the GSR input) but there is
nothing driving it (no pin or internal logic).  The GSR connection on
the STARTUP_SPARTAN3 primitive is an input and requires a driving
signal.

The GSR input then essentially provides a "stealth" connection to every
flip-flop within the FPGA.  No further connections are required.  You
still have a second independent control to individual flip-flop via the
set/reset inputs.

BTW, the GSR (Global Set/Reset) function can save quite a bit of logic
when migrating a design from an ASIC.  In an ASIC, you need a global
connection to all the flip-flops to place them in a pre-defined state.
In the FPGA, the flip-flops are automatically set/reset (depending on
the flip-flop primitive used) at the very end of configuration, just
before your FPGA applications starts operating.  Furthermore, you can
set/reset all the flip-flops at any time via the GSR input.

If you are interested, Ken Chapman has a good article (as always) on
the topic at ...

Get Smart About Reset (Think Local, Not Global)
http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sTechX_ID=kc_smart_reset

---------------------------------
Steven K. Knapp
Applications Manager, Xilinx Inc.
General Products Division
Spartan-3/-3E FPGAs
http://www.xilinx.com/spartan3e
---------------------------------
The Spartan(tm)-3 Generation:  The World's Lowest-Cost FPGAs.


Article: 100388
Subject: Re: Xst warning, dangling RAMB16B output
From: "Steve Knapp (Xilinx Spartan-3 Generation FPGAs)" <steve.knapp@xilinx.com>
Date: 7 Apr 2006 09:26:12 -0700
Links: << >>  << T >>  << A >>

Arlet wrote:

[ ... snip ...]

> I'm using XST, ISE Webpack 6.2

At a minimum, I would like to encourage you to update to a more recent
release.  WebPACK is now at version 8.1i.  There were a number of
improvements in implementation quality between ISE 6.2i and 8.1i.
http://www.xilinx.com/ise/logic_design_prod/webpack.htm

-- Steve Knapp


Article: 100389
Subject: who know what is the problem
From: zhangxun0501@gmail.com
Date: 7 Apr 2006 09:31:45 -0700
Links: << >>  << T >>  << A >>
who know what is the problem: those four error


C:\copy_project\exemple6\top_ise>map processor_stub.ngd
Release 8.1.03i - Map I.27
Copyright (c) 1995-2005 Xilinx, Inc.  All rights reserved.
Using target part "4vfx12ff668-10".
Mapping design into LUTs...
ERROR:LIT:248 - CASCADEINA pin of RAMB16 symbol

"top/plb_bram_if_cntlr_1_bram/plb_bram_if_cntlr_1_bram/physical_group_BRAM_Di
   n_A<0>/ramb16_0" can be sourced only from a CASCADEOUTA of a
different
   RAMB16. Also, the CASCADEOUTA pin on a RAMB16 can source only a
single
   CASCADEINA pin of a different RAMB16.
ERROR:LIT:249 - CASCADEINB pin of RAMB16 symbol

"top/plb_bram_if_cntlr_1_bram/plb_bram_if_cntlr_1_bram/physical_group_BRAM_Di
   n_A<0>/ramb16_0" can be sourced only from a CASCADEOUTB of a
different
   RAMB16. Also, the CASCADEOUTB pin on a RAMB16 can source only a
single
   CASCADEINB pin of a different RAMB16.
ERROR:LIT:301 - EMACDCRACK pin of PPC405_ADV symbol
   top/ppc405_0/ppc405_0/PPC405_ADV_i can be driven only by pin
EMACDCRACK of an
   EMAC.
ERROR:LIT:304 - EMACDCRDBUS bus of PPC405_ADV symbol
   top/ppc405_0/ppc405_0/PPC405_ADV_i can be driven only by bus
EMACDCRDBUS of
   an EMAC.
Errors found during logical drc.



thanks advance


Article: 100390
Subject: Re: rather simple gsr Q
From: "Roger Bourne" <rover8898@hotmail.com>
Date: 7 Apr 2006 09:41:14 -0700
Links: << >>  << T >>  << A >>

> The GSR input then essentially provides a "stealth" connection to every
> flip-flop within the FPGA.  No further connections are required.  You
> still have a second independent control to individual flip-flop via the
> set/reset inputs.
>

I think I see. All the FFs (and similar modules that require resets or
presets) in the FPGA are ALREADY connected to a secondary unshown gsr
network. This is the fpga's self-generating internal gsr network that
the fpga provides upon power-on. All FFs have additionnaly a second
user-accessible async. reset or preset that can be simply grounded if
not used. Right ?

However, If I wanted to access the fpga's self-generating internal gsr
net for initialization purposes of let's say a custom-made logic cell
in which there is memory (in other words, feedbacking an even number of
inverting-logic cells.... Actually, I do not if feedback is possible
for fpgas (it was always possible in asics...)), how would I then
invoke the fpga's self-generating internal gsr net?

Also I tried to find the fpga's self-generating internal gsr net in a
modelsim simulation. Alas no cigar. Would it be possible to visualize
the fpga's self-generating internal gsr net during simulation?

Thx in advance for all your help.
-Roger


Article: 100391
Subject: Re: Infer dual-clock block RAM for Xilinx
From: "Amal" <akhailtash@gmail.com>
Date: 7 Apr 2006 09:42:53 -0700
Links: << >>  << T >>  << A >>
Google is not broken, but it's not quite what I need.  A dual-clock,
dual-port block memory mapped to RAMB16 using VHDL!


Article: 100392
Subject: Re: Infer dual-clock block RAM for Xilinx
From: "Symon" <symon_brewer@hotmail.com>
Date: Fri, 7 Apr 2006 18:09:13 +0100
Links: << >>  << T >>  << A >>
D'oh, my mistake, I missed the dual-clock requirement. I know the dual clock 
inference didn't work the last time I tried it, maybe 2 years ago. At least, 
I mean I didn't find a solution except to instantiate the things. If you do 
manage to crack it, it'd be cool if you could post your solution.
Thanks & good luck, Syms.
"Amal" <akhailtash@gmail.com> wrote in message 
news:1144428173.435579.123230@g10g2000cwb.googlegroups.com...
> Google is not broken, but it's not quite what I need.  A dual-clock,
> dual-port block memory mapped to RAMB16 using VHDL!
> 



Article: 100393
Subject: Re: FSL to VHDL interface
From: "Dale" <dale.prather@gmail.com>
Date: 7 Apr 2006 11:11:06 -0700
Links: << >>  << T >>  << A >>
I want to thank both of you for helping me understand this.  I think I
finally have my brain wrapped around this twisted stuff, thanks to you.
 I'm on my way to getting it to work.  I was hoping to find a way
around this tunnel method.  That's not going to happen, but in trying
to do so, I have a much better understanding of how FSLs, EDK, MHSs,
MPDs and the associated syntaxes work.

Thanks,
Dale


Article: 100394
Subject: Re: Testing sample Aurora design on ML321 board
From: "billu" <bkamakot@gmail.com>
Date: 7 Apr 2006 12:25:49 -0700
Links: << >>  << T >>  << A >>
Hi There,

Thx for ur responses.

> Probably the simplest test is to monitor the channel_up signal out of
> the core. Your monitoring should verify that the signal is steady, too.
> If that is good, then the link is good and you should be able to
> send/receive data with no problem.

I'm assuming you'll need to write some HDL code to configure what
transceivers you want to use and enable monitoring of the channel up,
right? Is there any sample code available that does something like
that. (dont have any experience w/ hdl). On that note,  can the Aurora
Bus functional model do something like that. I still cant completely
understand what the bus functional model does.

- Bala


Duane Clark wrote:
> billu wrote:
> > Hi There,
> >
> > I've managed to compile a sample aurora protocol design using
> > Coregenerator, and simulated it using ModelSim. I have a couple of
> > questions at this point.
> >
> > I'm trying to download the design onto the board using IMPACT. All the
> > processes (Program, Get Device ID, Read Status Register.. ) seem to
> > work except the Verify process. Is that something that I should be
> > concerned about.Can I assume that design has been uploaded to the
> > board, once I run program, and it says program successful?
>
> I would say, yes you should be concerned if the verify doesn't work. But
> if the board seems to be running okay... ?
>
> > How do I test the design on the board. Is there a simple to way to
> > demonstrate a link between two transceivers and monitor the status. I'm
> > guessing theres something possible with Chipscope, but I dont have
> > access to the program.
>
> Probably the simplest test is to monitor the channel_up signal out of
> the core. Your monitoring should verify that the signal is steady, too.
> If that is good, then the link is good and you should be able to
> send/receive data with no problem.


Article: 100395
Subject: Re: rather simple gsr Q
From: "Steve Knapp (Xilinx Spartan-3 Generation FPGAs)" <steve.knapp@xilinx.com>
Date: 7 Apr 2006 12:53:45 -0700
Links: << >>  << T >>  << A >>

Roger Bourne wrote:
> > The GSR input then essentially provides a "stealth" connection to every
> > flip-flop within the FPGA.  No further connections are required.  You
> > still have a second independent control to individual flip-flop via the
> > set/reset inputs.
> >
>
> I think I see. All the FFs (and similar modules that require resets or
> presets) in the FPGA are ALREADY connected to a secondary unshown gsr
> network. This is the fpga's self-generating internal gsr network that
> the fpga provides upon power-on. All FFs have additionnaly a second
> user-accessible async. reset or preset that can be simply grounded if
> not used. Right ?

Correct.  BTW, if you are using schematic capture, there are also
flip-flop primitives without set or reset, which saves you from tying
off unused inputs.

> However, If I wanted to access the fpga's self-generating internal gsr
> net for initialization purposes of let's say a custom-made logic cell
> in which there is memory (in other words, feedbacking an even number of
> inverting-logic cells.... Actually, I do not if feedback is possible
> for fpgas (it was always possible in asics...)), how would I then
> invoke the fpga's self-generating internal gsr net?

I'm not sure what you mean here.  The GSR network is automatically
pulsed at the end of configuration.  Your FPGA design can also assert
GSR by driving the GSR input to the STARTUP_SPARTAN3 primitive.

> Also I tried to find the fpga's self-generating internal gsr net in a
> modelsim simulation. Alas no cigar. Would it be possible to visualize
> the fpga's self-generating internal gsr net during simulation?

Take a look at the following ...
http://toolbox.xilinx.com/docsan/xilinx8/books/docs/sim/sim.pdf (pages
204, 253)

http://toolbox.xilinx.com/docsan/xilinx8/books/data/docs/dev/dev0188_27.html


-- Steve Knapp


Article: 100396
Subject: Re: LVDS in Cyclone-II (or in Spartan-3E)
From: "Steve Knapp (Xilinx Spartan-3 Generation FPGAs)" <steve.knapp@xilinx.com>
Date: 7 Apr 2006 13:05:14 -0700
Links: << >>  << T >>  << A >>
Brian Davis wrote:

[ ... snip ...]
> >
>  Well, those mysterious "fours" seem to have reappeared across
> the board again for the S3E differential drivers in VQ/PQ packages,
> with the spiffy well-balanced current mode drivers once again
> inconsistently assigned the same limit as have the older voltage
> mode, psuedo-differential, CMOS-with-resistors BLVDS outputs.
>
>  Those mystery fours also do not show the expected improvement in the
> smaller VQ package as do both the single ended standards and the latest
> Spartan-3 SSO limits for their current mode differential drivers.

The current Spartan-3E data sheet does indeed show those mysterious
"fours".

We're in the process of updating the Spartan-3E numbers and I expect
the mysterious 4's to improve to 6's in the next data sheet release for
LVDS, RSDS, and miniLVDS I/O standards.  Effectively, this means that
you can practically use all available I/O on a bank for LVDS, RSDS, or
miniLVDS outputs (okay, you miss one or two pins on the PQ208).

The Spartan-3 SSO confusion that you mentioned happened due to the
methodology we used at the time.  Previously, the SSO numbers were
generated strictly from simulation models, which always suffered from
huge, conservative guardbands on new processes.  Spartan-3 was one of
the first commercially available 90 nm devices.  The Spartan-3 SSO
numbers started out very low and improved once we were able to back up
the numbers with real silicon.
---------------------------------
Steven K. Knapp
Applications Manager, Xilinx Inc.
General Products Division
Spartan-3/-3E FPGAs
http://www.xilinx.com/spartan3e
---------------------------------
The Spartan(tm)-3 Generation:  The World's Lowest-Cost FPGAs.


Article: 100397
Subject: Re: rather simple gsr Q
From: "Roger Bourne" <rover8898@hotmail.com>
Date: 7 Apr 2006 14:17:59 -0700
Links: << >>  << T >>  << A >>

> > However, If I wanted to access the fpga's self-generating internal gsr
> > net for initialization purposes of let's say a custom-made logic cell
> > in which there is memory (in other words, feedbacking an even number of
> > inverting-logic cells.... Actually, I do not if feedback is possible
> > for fpgas (it was always possible in asics...)), how would I then
> > invoke the fpga's self-generating internal gsr net?
>
> I'm not sure what you mean here.  The GSR network is automatically
> pulsed at the end of configuration.  Your FPGA design can also assert
> GSR by driving the GSR input to the STARTUP_SPARTAN3 primitive.
>

What I meant by the above was:
Is there a way to insert the FPGA's GSR net in a shematic design?

The reason I was asking the question was because I was thinking about
the situation were nand & inv gates are used to constructed a bulky
(and slow) memory element. (If such a construction is permitted in an
fpga) . In that situation, the fpga's gsr net would come in handy for
the memory's element initialization. 

-Roger


Article: 100398
Subject: Re: who know what is the problem
From: Ray Andraka <ray@andraka.com>
Date: Fri, 07 Apr 2006 18:13:05 -0400
Links: << >>  << T >>  << A >>

read the Virtex4 user's guide chapter on using BRAM.  The cascade in/out 
can only be connected directly to one other BRAM.  If you are not using 
them, leave them open.

Article: 100399
Subject: Re: Testing sample Aurora design on ML321 board
From: Duane Clark <junkmail@junkmail.com>
Date: Fri, 07 Apr 2006 22:36:59 GMT
Links: << >>  << T >>  << A >>
billu wrote:
> Hi There,
> 
> Thx for ur responses.
> 
>> Probably the simplest test is to monitor the channel_up signal out of
>> the core. Your monitoring should verify that the signal is steady, too.
>> If that is good, then the link is good and you should be able to
>> send/receive data with no problem.
> 
> I'm assuming you'll need to write some HDL code to configure what
> transceivers you want to use and enable monitoring of the channel up,
> right? Is there any sample code available that does something like
> that. (dont have any experience w/ hdl). On that note,  can the Aurora
> Bus functional model do something like that. I still cant completely
> understand what the bus functional model does.

Perhaps you need to discuss what it is you are trying to do, and in what 
context (homework, tinkering, work, ?).

As for an Aurora bus functional model; generally bus functional models 
are for simulation only. The Aurora core is simple enough that such a 
model is likely overkill, though I have never looked at one for the 
Aurora core (frankly, I did not know it existed).



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