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 111850

Article: 111850
Subject: replacement for Altera EPCS64
From: "vasile" <piclist9@gmail.com>
Date: 11 Nov 2006 06:34:03 -0800
Links: << >>  << T >>  << A >>
Hi,

Altera EPCS64 is a 64Mbit serial flash memory used for AS configuration
in SOIC16 package.
The SOIC package is too big (around 10x10mm) for my PCB design.
I can't change the configuration system which is AS serial
configuration device programmed using download cable.

Do you know other serial flash memory which can be used with the
ALTERA's programming software and which can be found in a small flat
package ?

I've asked at Altera and get some banal answers about looking in the
datasheet, and changing the AS with other configuration methode (which
is more PCB space consumer than AS).

thx,


Article: 111851
Subject: Virtex-5 Webpack?
From: jonas@mit.edu
Date: 11 Nov 2006 07:57:35 -0800
Links: << >>  << T >>  << A >>
Hello! For a long time my lab purchased the lower-cost ISE Base-X kit,
which was recently discontinued and its functionality was rolled into
WebPack (which is available for free!) Base-X always seemed to contain
support for the two smallest of Xilinx's high-end devices. The latest
WebPack, however, does not contain support for the V5s. Is there a plan
to have V5 support in WebPack in the future?

I know the standard Xilinx line on this is "If you're doing high-end
development, ISE tools are not going to be a big part of your cost" but
in our environment where we have a bunch of students doing development
on prototype boards, the license costs can add up quickly.

Thanks, 
       ...Eric


Article: 111852
Subject: Re: Virtex-5 Webpack?
From: Frank Buss <fb@frank-buss.de>
Date: Sat, 11 Nov 2006 17:26:15 +0100
Links: << >>  << T >>  << A >>
jonas@mit.edu wrote:

> I know the standard Xilinx line on this is "If you're doing high-end
> development, ISE tools are not going to be a big part of your cost" but
> in our environment where we have a bunch of students doing development
> on prototype boards, the license costs can add up quickly.

Why not using Altera then? AFAIK the web edition of Quartus supports all
Altera FPGAs.

The only problem is when you use Linux: For Windows, Quartus is free, but
for Linux you have to pay for it, which makes development for me a bit
harder at work, because I'm using Linux for developing for an embedded
system and in parallel I need a second computer for synthesizing for the
FPGA on this system. Would be much better if Xilinx and Altera would
provide all development software for free for both platforms, maybe then
they would even sell more chips.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Article: 111853
Subject: Re: Virtex-5 Webpack?
From: "Slurp" <slip@slap.slop>
Date: Sat, 11 Nov 2006 16:43:18 -0000
Links: << >>  << T >>  << A >>

"Frank Buss" <fb@frank-buss.de> wrote in message 
news:yun4h7muz846.pwvoght3r698.dlg@40tude.net...
> jonas@mit.edu wrote:
>
>> I know the standard Xilinx line on this is "If you're doing high-end
>> development, ISE tools are not going to be a big part of your cost" but
>> in our environment where we have a bunch of students doing development
>> on prototype boards, the license costs can add up quickly.
>
> Why not using Altera then? AFAIK the web edition of Quartus supports all
> Altera FPGAs.
>
Nope. The web edition only supports the smallest Stratix I & II parts.

Slurp 



Article: 111854
Subject: Re: tri0 GSR = glbl.GSR;
From: "motty" <mottoblatto@yahoo.com>
Date: 11 Nov 2006 08:49:57 -0800
Links: << >>  << T >>  << A >>
I use the GUI (NCLaunch) to compile and elaborate and here is what I
do...

1)  I put the 'glbl.v' file in my simulation directory (same directory
that I point NCLaunch to as my 'design directory').
2)  I compile this file along with all my other Verilog files.
3)  I select both the glbl and whatever testfixture I am using and
elaborate those at the same time.
4)  Then you can sim as normal.

The above is doing the same as the command line options.  I just find
it easier and faster.  I am lazy though.  You could easily create
scripts for this if you want to.  If you don't use the GUI, then I
guess this post doesn't help!  But it took me a while to figure this
out and I couldn't find the answer here, so maybe it will help others.


Article: 111855
Subject: EDK post 7.1 Opinions
From: "motty" <mottoblatto@yahoo.com>
Date: 11 Nov 2006 09:02:09 -0800
Links: << >>  << T >>  << A >>
I was just wondering what others thought about the 'New 8.X' EDK.
Three people in my group at work have used the EDK since 6.1 and we are
all a little disappointed with the newest EDK's.  It's functionality is
the same, but the GUI and interfaces are all apparently totally
different.  There are things that we got used to using in the older
versions that are different here (ex. core version pull-down menus for
one).  I know that part of the problem is that we are used to the old.
But there are things that seem like the software to a step backwards.
I feel that the intuitive-ness has gone down.  I liked the flow of the
old software.  Creating the memory mapping was more intuitive in older
releases.  I liked the port and signal controls in the older as well.

So what do other users think?

We also ran into some problem with downloading the bit file into our
FPGA via the EDK.  For some reason, if we rebuild the project and try
to download, it doesn't work.  Our workaround that we discovered is
that if we 'wiggle' the JTAG we can download all we want.  And by
'wiggle' I mean using impact to either erase the PROM we have on board
or program it (any .mcs file -- it doesn't matter).  Keep in mind, we
are only trying to DOWNLOAD the bit file into the FPGA.  We aren't even
messing with the PROM.  This never occurred before EDK 8.2 and we have
confirmed it's a problem on multiple computers/setups.  We haven't
tried on any other board except ours.


Article: 111856
Subject: Re: Area Constraints in Xilinx
From: "RobJ" <rob@abc.net>
Date: Sat, 11 Nov 2006 17:23:22 GMT
Links: << >>  << T >>  << A >>
<ian.peikon@gmail.com> wrote in message 
news:1163181720.400625.238980@h48g2000cwc.googlegroups.com...
> Hi,
>
> I've been working on an FPGA project for a month or so now and I have
> finally finished the code.  Before I began I calculated the amount of
> BRAM and Distributed Ram that I had available and designed the code
> accordingly.  However after compilation I get the following results:
> Number of Slices:                   43734  out of   1200   3644% (*)
> Number of Slice Flip Flops:         19047  out of   2400   793% (*)
> Number of 4 input LUTs:             27654  out of   2400   1152% (*)
> Number of IOs:                         58
> Number of bonded IOBs:                 53  out of     96    55%
> Number of BRAMs:                      528  out of     10   5280% (*)
> Number of GCLKs:                        2  out of      4    50%
>

I'm curious which Xilinx device and package you're targeting. I didn't do an 
exhasutive search, but I didn't see any Virtex-II, or Spartan (2, 3, 3E) 
parts with the resources listed above.

Rob 



Article: 111857
Subject: Re: Virtex-5 Webpack?
From: "Antti Lukats" <antti@openchip.org>
Date: Sat, 11 Nov 2006 18:30:44 +0100
Links: << >>  << T >>  << A >>
"Slurp" <slip@slap.slop> schrieb im Newsbeitrag 
news:4555fdd2$0$8737$ed2619ec@ptn-nntp-reader02.plus.net...
>
> "Frank Buss" <fb@frank-buss.de> wrote in message 
> news:yun4h7muz846.pwvoght3r698.dlg@40tude.net...
>> jonas@mit.edu wrote:
>>
>>> I know the standard Xilinx line on this is "If you're doing high-end
>>> development, ISE tools are not going to be a big part of your cost" but
>>> in our environment where we have a bunch of students doing development
>>> on prototype boards, the license costs can add up quickly.
>>
>> Why not using Altera then? AFAIK the web edition of Quartus supports all
>> Altera FPGAs.
>>
> Nope. The web edition only supports the smallest Stratix I & II parts.
>
> Slurp
well altera webedition *DOES* support at least one part of each high end 
family
WebPack does *NOT* support V-5 at all

Antti 



Article: 111858
Subject: Re: Virtex-5 Webpack?
From: jonas@mit.edu
Date: 11 Nov 2006 10:26:27 -0800
Links: << >>  << T >>  << A >>

> The only problem is when you use Linux: For Windows, Quartus is free, but
> for Linux you have to pay for it, which makes development for me a bit
> harder at work, because I'm using Linux for developing for an embedded
> system and in parallel I need a second computer for synthesizing for the
> FPGA on this system. Would be much better if Xilinx and Altera would
> provide all development software for free for both platforms, maybe then
> they would even sell more chips.

Yea, I'm in the same boat -- my uClinux dev tools all run under linux,
and right now all the xilinx tools run really well on the same machine.
Plus, we've invested a lot of time and energy working with the xilinx
toolchain and hardware -- the thought of switching is somewhat scary!
    ...Eric


Article: 111859
Subject: Re: using FPGAs for synthesizing?
From: "JJ" <johnjakson@gmail.com>
Date: 11 Nov 2006 10:54:42 -0800
Links: << >>  << T >>  << A >>

Paul Leventis wrote:
> Hi Frank,
>
> There's not much in the CAD tool that could be easily sped up on an
> FPGA.  CAD tools have huge working sets (active memory) and spend a lot
> of their time jumping around through that memory.  Many key algorithms
> are manipulating graphs and this sort of stuff isn't easy to

Thats pretty much what I have been saying all along but into the wind
though.

> parallelize.  Spliting it into multiple threads for a CPU is tough
> enough -- going massively parallel in an FPGA (or heck, a GPU -- anyone
> read up on the G8800?) is much tougher.
>

Better to solve the Memory Wall problem first before going to multi
cores and compounding the problem.

> Plus think of the maintenance nightmare... each new alogrithm or tweak
> becomes a hardware change!
>
> - Paul


PCs are only blistering fast when given trivial problems such as video
coding where lots of grunt work gets done on small data blocks mostly
in some raster or linear order.

You can see that when you traverse a graph or tree or even a simple
linked list by randomly walking an array who's size is plotted from
small ranges to huge ranges what happens to the caches.

If the problem fits in L1 cache, memory access times are close enough
to 1ns that a tiny loop can probably scan memory in a few ns/entry and
do some useful work, all the caches work together to make the Memory
Wall just vanish.

Increase the range from L1 to L2 and the loop time sturts to increase
noticeably when little work is done. I bet that for most graph
traversals relatively little work is done per hop.

Further increases beyond L2 and it falls apart completely, 1ns can
become 100ns plus for every access if all nodes are fully randomly
allocated over a memory range of 100MB or so. On an older Athlon XP it
even reaches 400ns and a newer D805 reaches 130ns, that suggests the OS
gets called to fix up the TLB every accesss. (if anybody with a CoreDuo
wants to run the test for me let me know). I don't think the OS makes
much difference, same thing needs to happen to change the TLBs. Now if
the working set were bigger than the DRAM, you could factor in VM page
misses too and 1ns becomes a few ms.

I have proposed a solution to the Memory Wall but it requires taking a
hit elsewhere ie a Thread Wall and it requires multithreading both the
processor AND the MMU + Memory system. That allows both processors and
memory latency to be pretty well hidden and it requires using RLDRAM
with a high issue rate and much reduced latency as a total cache
replacement. All of its 8 banks can be used concurrently when used by
40 or so threads. The MMU hashes object references and indexes over the
address space and reorders bank access so that they get used in the
right order as they complete previous requests. The idea here is that
processor elements are cheap and memory access is the real limit and
that RLDRAM has about 20x more throughput than regular DRAM. When you
consider that the hashing MMU replaces TLBs so that 1.5 RLDRAM cycles
gives 1 useful random memory access while a true random DRAM access
will involve the OS fixing up TLBs with several hidden DRAM cycles per
application access.

In the real world I think most apps appear to hide the problem by
mixing up linear and random accesses so the drop in performance is far
less spectacular, but full time random graph traversal on huge working
sets reveals the nasty side of things.

So while you can't fix up your PC to effectively get low Memory Wall
you could bypass this by moving parts of FPGA/EDA apps into highly
threaded code on FPGA cpu cluster designed around such a RLDRAM system.
Around 10 Processor Elements running at same clock as RLDRAM clock
sharing memory accesses through a common shared MMU can reach upto 1500
integer register Mips and probably sustain half that with usual load,
store, branch rates with even access across the whole RLDRAM array. In
effect random access is even better now than linear access as it forces
all 8 banks to have even access loads. The hit is that the full
utilization needs 4 threads per PE so 40 threads sharing the MMU.
800Mips may not seem impressive but I bet a typical PC randomly walking
memory performs far worse.

Now if this sort of processor design were pushed into full custom ASIC,
300MHz FPGA clocks can become atleast 5x faster and the RLDRAM model
can also run 5x faster by adding a smaller upfront SRAM equivalent
model. Here the SRAM also relies on n way banking to cover slower cycle
times so 8 parallel 2ns cycles look equivalent to 0.25ns cycles with
effective 0.33ns average access times due to hash collisions. Each
usefull access supports about 5-10 opcodes so the overall throughput
scales with frequency again since the interleaving allows many memories
to run much slower than the processor MMU clock. Conventional single
threaded cpu designs demands all the parts run as fast as possible,
clearly an impossible goal for large memory useage. Both Raza and Sun
have effectively done this with 1.5GHz threaded processors but I
haven't seen the memory side go the same way yet.

Ironically all the talk about future 80 way Intel cores coming down the
pike is going to make the current Memory Wall problem far worse and it
will give you 80 threads to keep busy too.

The nice thing about putting some EDA code into FPGA cpus designed for
random walk throughput is that the individual PEs can also have special
opcodes added to help the EDA app. If you think in terms of
conventional MicroBlaze or Nios designs as being used for running FPGA
code, then you are just replicating conventional Memory Wall designs at
much slower clocks although full cache misses on very fast or very slow
cpus to same sort of primary DRAM will have same final limit.

I also suspect that if the Memory Wall is finally tackled as suggested,
Moore's Law would then allow the EDA host cpu to better track the EDA
problem, bigger chip designs can still be handled by processors that
actually did scale with frequency but the EDA tool must use atleast 20
threads to get the Memory Wall to level down. Those of us from the ASIC
world used to deal with floor planning and P/R times in the week time
frame so minutes or hours is still better.

While an FPGA hardwired version of EDA is probably not attractive,
perhaps just building a database engine to store and search the entire
working set useing FPGA to drive RLDRAM banks to guarantee fast
probes.might work, perhaps useing the HT bus with an Opteron.

regards

John Jakson

Anyway the paper is still at wotug, google for r16 fpga transputer.


Article: 111860
Subject: Re: I look for a wideband SERDES chip
From: John_H <newsgroup@johnhandwork.com>
Date: Sat, 11 Nov 2006 19:10:06 GMT
Links: << >>  << T >>  << A >>
A Serializer/Deserializer (SerDes) can be implemented as a hard silicon 
block with (relatively) clean PLL-based VCO or it can be implemented in 
general FPGA log, taking parallel data in to produce serial data (Ser) 
or taking in serial data and making it parallel (Des).  By using the 
inexpensive FPGAs capable of high LVDS I/O rates, you can get most of 
what you need pretty readily without resorting to the hard SerDes block 
which - while capable at the slow 622 Mb/s rate (in the SerDes realm 
it's slow) they are more geared toward STM-16 style rates.

You confuse me with the 933.12 MHz clock need since you're dealing with 
STM-4 rates as the basis.  If you have full STM data plus 50% overhead 
then I'd suggest having two channels plus clock rather than one channel 
plus clock would be prudent.

You are correct in that this scheme - fabric-based SerDes functionality 
- would require a separate clock for each independent timing source. 
Some hard SerDes blocks in the more expensive (higher functionality) 
FPGAs can do clock recovery but many of those require 8b/10b encoding 
which is *fine* if you're dealing with FPGA based distribution where you 
have complete control over both ends.

I still can't stress enough how any timing that passes through the FPGAs 
can be used for timing the data to the internal logic but *cannot* be 
used as a raw, clean timebase for the STM transmitters.

You might find a Xilinx App Note of interest, though the implementation 
is not well suited to the inexperienced FPGA designer.  Dealing with 
high speed chip-to-chip data transfer, the following App Note can 
deliver many parallel channels of STM-4 class speed.

http://www.xilinx.com/bvdocs/appnotes/xapp671.pdf

You might even find how to get around the one clock per connection 
requirement.  I haven't read through the app note thoroughly but I found 
it after I was mostly done with my own high speed deserializer.  The 
techniques in the app note may provide all the performance you need.

Arash wrote:
> Hello and thanks for your cooperation.
> Sorry, since I copied this script from another place, during the copy,
> the last question was not pasted correctly. Anyhow, my two questions
> were as follows:
> 
> 1- As I have seen in different vendors pages, most of the SERDES
> devices are placed after a protocol device. For transmitting SDH
> telecombus data is it necessary to implement a protocol on it or not.
> (Why protocol specification is required?).
> 2- Has anyone seen any SERDES chip which supports the  mentioned rates
> (19.44
> MHz and 77.76MHz) on its parallel side or not?
> 
> John_H wrote:
>> Since STM4 is only 622 Mb/s and you're posting on the FPGA board, you can
>> apply a SerDes from just about any FPGA to get to your rate  Many families
>> will also support 622 Mb/s in the standard I/Os.  The STM-4 rate is a target
>> for most FPGA vendors so they'll shoot at this as an achievable maximum on
>> standard I/O and a minimum on the SerDes as well.
>>
> First of all, SERDES is not available in any FPGA, and for example in
> Xilinx FPGA's, it is available in VIRTEX-II pro and the VIRTEX-4 and
> VIRTEX-5 familes. do you know any low price small FPGA which supports
> the SERDES feature as we want. (In our current design the telecombuses
> from the tributary cards are directly connected from the tributary
> cards to the FPGA on the OIU card).
> Meanwhile, if we don't want to have SERDES, and just use the ordinary
> I/O's for communication, we would need a (233.28MHz=19.44Mhz*12) 233.28
> MHz clock in each of the E1 tributary cards and a 933.12 MHz clock on
> the data card to transmit the 12-bit telecombuses serially. Meanwhile
> we should also transmit the 233.28 MHz and 933.12MHz clock on the
> backplane. Am I right? have you any other idea about this?
> 
>> The SerDes are often used after the protocol layer but isn't needed in an
>> application with protocol.  The FPGAs have this functionality as a more
>> generic function than you might perceive.
>>
>> Two cautions for your application:
>>
>> First, the clocks must be supplies separately for your links; the FPGA logic
>> doesn't deal well with plesiochronous signals alone though some SerDes
>> blocks might support some form of clock recovery.  If you have the local
>> clock available and can communicate that clock with the 622 Mb/s data, you
>> should be in good shape.
>>
>> Second, these signals can *not* be used for timing.  The jitter requirements
>> for the SDH signals are sincerely more strict that what you should expect
>> from the FPGAs.  As with most SDH designs, you should only introduce signals
>> onto the line that are within the ITU-T jitter limits.
>>
> They won't surely be used for timing.
>> As long as all your data shuffling is internal to your system and you're
>> retimed for all your transmitters with the appropriate low-jitter circuitry,
>> today's FPGAs can really carry you well.
>>
> But we should be sure that neither of theses 12 bits are shuffled.
> Because the  SDH chip  needs these 12 signals in its correct timing
> position.
>> Oh - and did you have two questions?
>>
>> - John_H
>>
>>
>> "Arash" <arash.majd@gmail.com> wrote in message
>> news:1163175421.380944.121850@h48g2000cwc.googlegroups.com...
>>> Hello
>>> I have got a problem in SERDES chip selection that I would be grateful
>>> if someone helps me in this regard. First, I explain the system that we
>>> have. We want to design an STM-4 SDH system which has  5 tributary
>>> cards and 1 optical STM-4 line card.The tributary cards are of two
>>> types : E1 card and data card. The E1 tributary card which contains an
>>> SDH E1 mapper,  has a 12-pin telecombus in 19.44 MHz rate in each of
>>> its transmit and receive directions (each card has 24 pins in
>>> backplane). but the Data tributary card which contains an EoS device on
>>> itself, has a 12-pin telecombus in 77.76MHz rate in each of the
>>> transmit and receive directions.The pslot of the optical line card is
>>> fixed but each of the tributary cards can sit in any  position of the 5
>>> tributary slots. to reduce the number of the pins on the backplane we
>>> want to serialize the telecombuses between the optical line card and
>>> the tributary cards. Since we do not know which of the tributary cards
>>> is inserted in in each slot we should select a SERDES which can
>>> serialize the data from both of the rates of 19.44 and 77.76 MHz (But
>>> during my searches in different vendors I haven't been able to find
>>> such a chip). I have got 2 questions.
>>> 1- As I have seen in different vendors pages, most of the SERDES
>>> devices are placed after a protocol device. for transmitting SDH
>>>
> 

Article: 111861
Subject: Re: Virtex-5 Webpack?
From: John_H <newsgroup@johnhandwork.com>
Date: Sat, 11 Nov 2006 19:15:33 GMT
Links: << >>  << T >>  << A >>
jonas@mit.edu wrote:
> Hello! For a long time my lab purchased the lower-cost ISE Base-X kit,
> which was recently discontinued and its functionality was rolled into
> WebPack (which is available for free!) Base-X always seemed to contain
> support for the two smallest of Xilinx's high-end devices. The latest
> WebPack, however, does not contain support for the V5s. Is there a plan
> to have V5 support in WebPack in the future?
> 
> I know the standard Xilinx line on this is "If you're doing high-end
> development, ISE tools are not going to be a big part of your cost" but
> in our environment where we have a bunch of students doing development
> on prototype boards, the license costs can add up quickly.
> 
> Thanks, 
>        ...Eric

If you're a university environment, contact Xilinx about their 
University Program.  While you might not get hotline support, you can 
get significantly greater tool access without paying full commercial 
license costs.  The FPGA vendors *are* interested in getting new FPGA 
designers into the field with solid tool experience.  Preferably their 
tools.

Article: 111862
Subject: Re: Xilinx Chipscope and EDK
From: "motty" <mottoblatto@yahoo.com>
Date: 11 Nov 2006 11:40:12 -0800
Links: << >>  << T >>  << A >>
Chipscope is great, but is it really non-intrusive?  In my experience,
not completely.

Just sayin.

Great tool!  I used to pull debug signals out to test pins.  Now that
is EXTREMELY intrusive and things can fall apart quickly.  But I was
also a lot dumber back then.  Now I am just sort of dumb.

Haven't tried the bus analysis cores.


Article: 111863
Subject: Re: I look for a wideband SERDES chip
From: "Arash" <arash.majd@gmail.com>
Date: 11 Nov 2006 12:21:45 -0800
Links: << >>  << T >>  << A >>
Thanks for your answer.
I am just reading the Application note to find out if it can help me or
not.
John_H wrote:
> A Serializer/Deserializer (SerDes) can be implemented as a hard silicon
> block with (relatively) clean PLL-based VCO or it can be implemented in
> general FPGA log, taking parallel data in to produce serial data (Ser)
> or taking in serial data and making it parallel (Des).  By using the
> inexpensive FPGAs capable of high LVDS I/O rates, you can get most of
> what you need pretty readily without resorting to the hard SerDes block
> which - while capable at the slow 622 Mb/s rate (in the SerDes realm
> it's slow) they are more geared toward STM-16 style rates.
>
> You confuse me with the 933.12 MHz clock need since you're dealing with
> STM-4 rates as the basis.  If you have full STM data plus 50% overhead
> then I'd suggest having two channels plus clock rather than one channel
> plus clock would be prudent.
>
In every parallel SDH telecombus, there are at least 4 other signals
apart from the 8 data bits which accompany the data signals to show the
different specific byte places in the frame. (Like the J1 pulse). For
example in an STM-4 system, there is a 77.76 MHz data bus accompanied
with one parity ,  one pin Clock,one C1J1V1 pin and one SPE pin and
hence the telecombus would be a 12 pin bus.

> You are correct in that this scheme - fabric-based SerDes functionality
> - would require a separate clock for each independent timing source.
> Some hard SerDes blocks in the more expensive (higher functionality)
> FPGAs can do clock recovery but many of those require 8b/10b encoding
> which is *fine* if you're dealing with FPGA based distribution where you
> have complete control over both ends.
>
> I still can't stress enough how any timing that passes through the FPGAs
> can be used for timing the data to the internal logic but *cannot* be
> used as a raw, clean timebase for the STM transmitters.
>
> You might find a Xilinx App Note of interest, though the implementation
> is not well suited to the inexperienced FPGA designer.  Dealing with
> high speed chip-to-chip data transfer, the following App Note can
> deliver many parallel channels of STM-4 class speed.
>
> http://www.xilinx.com/bvdocs/appnotes/xapp671.pdf
>
> You might even find how to get around the one clock per connection
> requirement.  I haven't read through the app note thoroughly but I found
> it after I was mostly done with my own high speed deserializer.  The
> techniques in the app note may provide all the performance you need.
>
> Arash wrote:
> > Hello and thanks for your cooperation.
> > Sorry, since I copied this script from another place, during the copy,
> > the last question was not pasted correctly. Anyhow, my two questions
> > were as follows:
> >
> > 1- As I have seen in different vendors pages, most of the SERDES
> > devices are placed after a protocol device. For transmitting SDH
> > telecombus data is it necessary to implement a protocol on it or not.
> > (Why protocol specification is required?).
> > 2- Has anyone seen any SERDES chip which supports the  mentioned rates
> > (19.44
> > MHz and 77.76MHz) on its parallel side or not?
> >
> > John_H wrote:
> >> Since STM4 is only 622 Mb/s and you're posting on the FPGA board, you can
> >> apply a SerDes from just about any FPGA to get to your rate  Many families
> >> will also support 622 Mb/s in the standard I/Os.  The STM-4 rate is a target
> >> for most FPGA vendors so they'll shoot at this as an achievable maximum on
> >> standard I/O and a minimum on the SerDes as well.
> >>
> > First of all, SERDES is not available in any FPGA, and for example in
> > Xilinx FPGA's, it is available in VIRTEX-II pro and the VIRTEX-4 and
> > VIRTEX-5 familes. do you know any low price small FPGA which supports
> > the SERDES feature as we want. (In our current design the telecombuses
> > from the tributary cards are directly connected from the tributary
> > cards to the FPGA on the OIU card).
> > Meanwhile, if we don't want to have SERDES, and just use the ordinary
> > I/O's for communication, we would need a (233.28MHz=19.44Mhz*12) 233.28
> > MHz clock in each of the E1 tributary cards and a 933.12 MHz clock on
> > the data card to transmit the 12-bit telecombuses serially. Meanwhile
> > we should also transmit the 233.28 MHz and 933.12MHz clock on the
> > backplane. Am I right? have you any other idea about this?
> >
> >> The SerDes are often used after the protocol layer but isn't needed in an
> >> application with protocol.  The FPGAs have this functionality as a more
> >> generic function than you might perceive.
> >>
> >> Two cautions for your application:
> >>
> >> First, the clocks must be supplies separately for your links; the FPGA logic
> >> doesn't deal well with plesiochronous signals alone though some SerDes
> >> blocks might support some form of clock recovery.  If you have the local
> >> clock available and can communicate that clock with the 622 Mb/s data, you
> >> should be in good shape.
> >>
> >> Second, these signals can *not* be used for timing.  The jitter requirements
> >> for the SDH signals are sincerely more strict that what you should expect
> >> from the FPGAs.  As with most SDH designs, you should only introduce signals
> >> onto the line that are within the ITU-T jitter limits.
> >>
> > They won't surely be used for timing.
> >> As long as all your data shuffling is internal to your system and you're
> >> retimed for all your transmitters with the appropriate low-jitter circuitry,
> >> today's FPGAs can really carry you well.
> >>
> > But we should be sure that neither of theses 12 bits are shuffled.
> > Because the  SDH chip  needs these 12 signals in its correct timing
> > position.
> >> Oh - and did you have two questions?
> >>
> >> - John_H
> >>
> >>
> >> "Arash" <arash.majd@gmail.com> wrote in message
> >> news:1163175421.380944.121850@h48g2000cwc.googlegroups.com...
> >>> Hello
> >>> I have got a problem in SERDES chip selection that I would be grateful
> >>> if someone helps me in this regard. First, I explain the system that we
> >>> have. We want to design an STM-4 SDH system which has  5 tributary
> >>> cards and 1 optical STM-4 line card.The tributary cards are of two
> >>> types : E1 card and data card. The E1 tributary card which contains an
> >>> SDH E1 mapper,  has a 12-pin telecombus in 19.44 MHz rate in each of
> >>> its transmit and receive directions (each card has 24 pins in
> >>> backplane). but the Data tributary card which contains an EoS device on
> >>> itself, has a 12-pin telecombus in 77.76MHz rate in each of the
> >>> transmit and receive directions.The pslot of the optical line card is
> >>> fixed but each of the tributary cards can sit in any  position of the 5
> >>> tributary slots. to reduce the number of the pins on the backplane we
> >>> want to serialize the telecombuses between the optical line card and
> >>> the tributary cards. Since we do not know which of the tributary cards
> >>> is inserted in in each slot we should select a SERDES which can
> >>> serialize the data from both of the rates of 19.44 and 77.76 MHz (But
> >>> during my searches in different vendors I haven't been able to find
> >>> such a chip). I have got 2 questions.
> >>> 1- As I have seen in different vendors pages, most of the SERDES
> >>> devices are placed after a protocol device. for transmitting SDH
> >>>
> >


Article: 111864
Subject: Re: Stratix-III announced
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Sun, 12 Nov 2006 10:05:27 +1300
Links: << >>  << T >>  << A >>
unknown@aol.com wrote:

> Personnaly, I'm also waiting for Cyclone III. Looks promising.
> By the way, I've been told that MAX III is also on the way ... and that NIOS II will be 
> supported :o) 

Yes, but with how much left over ?! :)

IIRC Xilinx have a MB Coolrunner demo, that surely no one has ever 
deployed in the field - but I did see it as a good tools-flow tester.

-jg


Article: 111865
Subject: Re: Stratix-III announced
From: "Antti" <Antti.Lukats@xilant.com>
Date: 11 Nov 2006 14:02:04 -0800
Links: << >>  << T >>  << A >>
Jim Granville schrieb:

> unknown@aol.com wrote:
>
> > Personnaly, I'm also waiting for Cyclone III. Looks promising.
> > By the way, I've been told that MAX III is also on the way ... and that NIOS II will be
> > supported :o)
>
> Yes, but with how much left over ?! :)
>
> IIRC Xilinx have a MB Coolrunner demo, that surely no one has ever
> deployed in the field - but I did see it as a good tools-flow tester.
>
> -jg

IIRC wrong.
there is special PLD version of the PicoPlaze but MB never fits any
xilinx PLD

Antti


Article: 111866
Subject: Re: Area Constraints in Xilinx
From: ian.peikon@gmail.com
Date: 11 Nov 2006 16:03:57 -0800
Links: << >>  << T >>  << A >>
I'm using the Spartan 3.
RobJ wrote:
> <ian.peikon@gmail.com> wrote in message
> news:1163181720.400625.238980@h48g2000cwc.googlegroups.com...
> > Hi,
> >
> > I've been working on an FPGA project for a month or so now and I have
> > finally finished the code.  Before I began I calculated the amount of
> > BRAM and Distributed Ram that I had available and designed the code
> > accordingly.  However after compilation I get the following results:
> > Number of Slices:                   43734  out of   1200   3644% (*)
> > Number of Slice Flip Flops:         19047  out of   2400   793% (*)
> > Number of 4 input LUTs:             27654  out of   2400   1152% (*)
> > Number of IOs:                         58
> > Number of bonded IOBs:                 53  out of     96    55%
> > Number of BRAMs:                      528  out of     10   5280% (*)
> > Number of GCLKs:                        2  out of      4    50%
> >
>
> I'm curious which Xilinx device and package you're targeting. I didn't do an
> exhasutive search, but I didn't see any Virtex-II, or Spartan (2, 3, 3E)
> parts with the resources listed above.
> 
> Rob


Article: 111867
Subject: Re: Area Constraints in Xilinx
From: "Matthew Hicks" <mdhicks2@uiuc.edu>
Date: Sat, 11 Nov 2006 21:38:45 -0600
Links: << >>  << T >>  << A >>
Sorry, I assumed that you used the primitives to instantiate the BRAM or 
wrote it so the synthesis engine would infer it (how I like to do it).  I 
was guessing that you had other heavy weight cores that weren't just 
instantiating built-in primitives.  An example would be a FIFO.


---Matthew Hicks


<ian.peikon@gmail.com> wrote in message 
news:1163231653.549534.187530@k70g2000cwa.googlegroups.com...
> Yes, I am using IP cores to generate the blockrams, but I only
> instantiate 5 of them at 8x16 (hardly the 520 that ISE claims).
> Matthew Hicks wrote:
>> To do much useful in 500 lines of code and have that resource utilization 
>> as
>> the output, my guess is that you are using a few IP cores which take up
>> those resources.
>>
>>
>> ---Matthew Hicks
>>
>>
>> <ian.peikon@gmail.com> wrote in message
>> news:1163181720.400625.238980@h48g2000cwc.googlegroups.com...
>> > Hi,
>> >
>> > I've been working on an FPGA project for a month or so now and I have
>> > finally finished the code.  Before I began I calculated the amount of
>> > BRAM and Distributed Ram that I had available and designed the code
>> > accordingly.  However after compilation I get the following results:
>> > Number of Slices:                   43734  out of   1200   3644% (*)
>> > Number of Slice Flip Flops:         19047  out of   2400   793% (*)
>> > Number of 4 input LUTs:             27654  out of   2400   1152% (*)
>> > Number of IOs:                         58
>> > Number of bonded IOBs:                 53  out of     96    55%
>> > Number of BRAMs:                      528  out of     10   5280% (*)
>> > Number of GCLKs:                        2  out of      4    50%
>> >
>> > I don't really see how any of this is possible.  I instantiated 5
>> > BRAM's.  Where does it come up with 528?  Additionally where do the
>> > flipflops, slices, and LUT's come from?  My code is only ~500 lines, I
>> > don't even know how I coded for this much logic?!!!
>> >
>> > PLEASE HELP!!
>> >
> 



Article: 111868
Subject: SDRAM of Spartan 3E
From: "fath" <Johnathn@gmail.com>
Date: 11 Nov 2006 23:01:47 -0800
Links: << >>  << T >>  << A >>
Hi, I am new on FPGA. I am planning to buy a spartan3e starter kit. But
I don't have idea if it has enough resource for my application. My
application may need a lot of memory. The on board memory of spartan3e
such as distributed RAM and block RAM may not be enough.

So my question is can I use DDR SDRAM as an additional memory to save
the coefficients when block RAM is not enough? If not, then what can it
be used for? What is the difference between DDR SDRAM and block RAM? Is
DDR SDRAM much slower than block RAM?


Article: 111869
Subject: SPI module in FPGA
From: "firebird" <helluvanengineer@gmail.com>
Date: 12 Nov 2006 00:36:37 -0800
Links: << >>  << T >>  << A >>
I am trying to write code for a SPI circuit (in VHDL) for the Altera
Cyclone II FPGA.  I think I understand the implementation of
essentially what amounts to a shift register.  However, what is a good
way to deal with the serial clock.  The FPGA will act as a master
interfacing with a slave A/D converter that supports SPI interface.
Thus, the FPGA will need to generate the SPI clock.  The FPGA will
contain a simple processor implementation.  I think the processor clock
can be used to derive the SPI clock, but would it better to provide an
independent clock for the SPI?  If so, what is a good way to do this?
I am not much experienced in FPGA design, so any help or
references/links would be greatly appreciated.

Thanks!


Article: 111870
Subject: EDK : path set
From: "Thang Nguyen" <airthang@yahoo.com>
Date: Sun, 12 Nov 2006 01:17:00 -0800
Links: << >>  << T >>  << A >>
Hi, After installing EDK 8.1i and update to SP 2, I meet this error when run the EDK: error: general error in xps-sdk launch. could not set cygwin path Could anyone tell me what is this error and how to fix it? Thank you so much, Thang Nguyen

Article: 111871
Subject: Re: SDRAM of Spartan 3E
From: Frank Buss <fb@frank-buss.de>
Date: Sun, 12 Nov 2006 11:46:11 +0100
Links: << >>  << T >>  << A >>
fath wrote:

> So my question is can I use DDR SDRAM as an additional memory to save
> the coefficients when block RAM is not enough? If not, then what can it
> be used for? What is the difference between DDR SDRAM and block RAM? Is
> DDR SDRAM much slower than block RAM?

The Spartan3E starter kit has 512 Mbit (64 Mbyte) DDR SDRAM. You use the
reference implementation for accessing it:
 
http://www.xilinx.com/support/software/memory/protected/index.htm

(you need to register first for the memory section of the Xilinx site, it's
free, then you can download "Spartan-3E DDR Reference Design for the
Spartan 3E Starter Kit"). The only drawback is, that this reference design
needs an external 133 MHz oscillator. I've tried to generate the clock from
the 50 MHz on-board oscillator with a DCM, but the RAM access was
unreliable with the DCM clock, I don't know why. So you have this nice 64
Mbyte RAM, but looks like currently there is no free implementation for
accessing it out of the box, without buying and building extra parts.

Block RAM is integrated on the FPGA and is faster: You can clock it with
230 MHz with speed grade -4 devices, which is on the starter kit. And you
don't need complicated I/O controller for using it, like with the DDR
SDRAM, which is an external chip. For the starter kit FPGA version you have
20 block RAMs, each with 18,432 bits, so you'll have about 46 Kbyte.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Article: 111872
Subject: Re: SPI module in FPGA
From: "Eli Bendersky" <eliben@gmail.com>
Date: 12 Nov 2006 02:47:11 -0800
Links: << >>  << T >>  << A >>

firebird =EB=FA=E1:
> I am trying to write code for a SPI circuit (in VHDL) for the Altera
> Cyclone II FPGA.  I think I understand the implementation of
> essentially what amounts to a shift register.  However, what is a good
> way to deal with the serial clock.  The FPGA will act as a master
> interfacing with a slave A/D converter that supports SPI interface.
> Thus, the FPGA will need to generate the SPI clock.  The FPGA will
> contain a simple processor implementation.  I think the processor clock
> can be used to derive the SPI clock, but would it better to provide an
> independent clock for the SPI?  If so, what is a good way to do this?
> I am not much experienced in FPGA design, so any help or
> references/links would be greatly appreciated.
>

You can easily generate the SPI clock by deriving it from your main CPU
clock, there's no problem with this. Note, however, that you won't be
able to have a SPI clock faster than Fclk / 2 where Fclk is your CPU
clock. This shouldn't be a problem, as in 99% of the cases SPI
communication is slower than processor speed.


Article: 111873
Subject: Power-on reset
From: "Borge" <borge.strand@gmail.com>
Date: 12 Nov 2006 04:48:00 -0800
Links: << >>  << T >>  << A >>
Is there a dedicated power-on reset function in Verilog? What I want to
achieve is that my own reset functionality will be executed when the
FPGA (Xilinx Spartan3/400) undergoes power-on reset.

Maybe power-on reset is available as a Xilix core, but I haven't been
able to find anything like that.

I was hoping to avoid external POR circuitry.


Thanks,

Borge

P.S. Cross-posted to comp.lang.verilog


Article: 111874
Subject: Re: Xilinx Partition for EDIF Flow (synthesis synplify)
From: kanglc@gmail.com
Date: 12 Nov 2006 06:25:03 -0800
Links: << >>  << T >>  << A >>
John,

I did that, but I can't set partitions on the lower-level edf because
ISE do not show it in the process window. Why I wanted to do this is
because MAP takes 3 hours, and I want to use partitions to speed up the
implementation time. According to Xilinx this is the new flow, as
compared to the old -gf guide file. It seems that this flow only works
for top-level hdl, not edf.

John_H wrote:
> Try specifying only the top level edif file and include a macro search
> path for the translate stage to allow the tool to find the other edifs.
>   This is how the .ngo files are included for some Xilinx cores; perhaps
> it's identical with the edif-only flow.




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