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 51575

Article: 51575
Subject: Re: Multiple FPGA-boards integration issues
From: Rene Tschaggelar <tschaggelar@dplanet.ch>
Date: Thu, 16 Jan 2003 20:07:59 +0100
Links: << >>  << T >>  << A >>
Prashant wrote:
> Hi,
> 
> I have an FPGA board from Altera that I use for my prototyping needs.
> The board has a single FPGA on it and an oscillator for 40MHz. I have
> to integrate this board with another board (type of second board
> unknown as yet) and some issues with such an integration just hit my
> head. There also may be issues I haven't thought of as yet. Guessed
> this may be a question to ask people for advice.
> 
> 1. Since the FPGA needs to work @ 40 MHz, can I get the same speeds on
> the board. What sort of speeds can be expected from data transfers
> using board interconnects between the two boards in question ?
> Obviously, if it was slower than the 40MHz requirement I have, the
> integration between the two boards would be impossible. But I haven't
> seen a mention of the board speeds in the data sheet of the board.
> This is probably a very common issue for a lot of prototyping that
> goes on in the industry. Any ideas ?
> 
> 2. Clock syncronization between the two boards is another issue. I can
> think of one way to do it. Use a pll in one FPGA device and take an
> output of the clock from this FPGA (FPGA 1). Supply this output clock
> of FPGA 1 as the input clock to FPGA 2 on the second board. Would this
> work and if so, Is this the right way ? What other ways would be used
> if any ? Which would be more efficient in terms of clock skew ?
> 
> 3. What design methodology would apply to integration of more than 2
> boards ? My guess is it would be similar to integration of 2 boards.
> 
> 4. Is it possible to integrate a board with a Xilinx device to a board
> with an Altera device ?


Interfacing FPGAs from different vendors is not a problem as long as
the logic levels match.  And the speed ?
You definitely have least problems when the clocks are in sync, eg
by running from just one clock. Some chips have internal mutipliers,
and for integer multiples they are in sync.
If you have two different clocks a Flipflop, or rather two of them
can do the synchonization.
Wouldn't it even be possible to integerate everything into one device ?

While a design spread over multiple chips are much harder to simulate,
it might be cheaper to do a board with everything in one chip.

Rene
-- 
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net


Article: 51576
Subject: Re: Off Topic: Single Board Computers?
From: johnjakson@yahoo.com (john jakson)
Date: 16 Jan 2003 11:28:35 -0800
Links: << >>  << T >>  << A >>
Terry Herter <tlh10@cornell.edu> wrote in message news:<3E24B39E.272225A5@cornell.edu>...
> Sorry...should have been more informative.  Looking for a 19" rackmount
> system...with a passive backplane and a single board computer...6U type
> size...etc.  Desktop PCI in a more rugged frame...
> 
> Thanks.
> 
> "Nicholas C. Weaver" wrote:
> 
> > In article <3E248F61.77E1748E@cornell.edu>,
> > Terry Herter  <tlh10@cornell.edu> wrote:
> > >Off topic question...but I suspect many will have some insight...
> > >
> > >Looking for a good single board computer/passive backplane in a rack
> > >mount.
> > >
> > >Can anyone suggest a good company to deal with, that just may be around
> > >in a few years to come?
> >
> > How small/what backplane?
> >
> > Eg, Via makes a nice all-in-one PC motherboard (C3 processor, chipset,
> > video, audio, 100 mb ethernet, USB2, firewire) which retails for <$150
> > with a 900 MHz processor, <$130 for a FANLESS 600 MHz processor, and
> > is 17cm x 17cm in dimension (mini-ITX form factor)
> >
> > http://www.viavpsd.com/product/epia_m_spec.jsp?motherboardId=81
> > --
> > Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

google "single board computer/passive backplane in a rack" 
looks interesting

Article: 51577
Subject: adaptive filter with many zero input
From: dhan@ecel.ufl.edu (Dongho)
Date: 16 Jan 2003 11:56:12 -0800
Links: << >>  << T >>  << A >>
Suppose 10 tap adaptive FIR filter and there are lots of zeros in
input, say 2 out of 10. So I don't need 10 multipliers to muliply 10
inputs and coefs because of many zero inputs(I need 2 multipliers).
After calculating sum of inner product I need to update the coefs.
How to save multipliers to implement adaptive FIR for this case?
Thanks

Article: 51578
Subject: Re: Schematic design approach compared to VHDL entry approach
From: Keith R. Williams <krw@btv.ibm.com>
Date: Thu, 16 Jan 2003 15:07:43 -0500
Links: << >>  << T >>  << A >>
In article <v2c27hcn3mmr95@corp.supernews.com>, austin@da98rkroom.com 
says...
> Keith,
> 
> > I guess I don't quite see the process yet. The top level is a schematic
> > block, and the bottom level is gates, but the intermediate hierarchical
> > objects are flow charts?
> 
> The top level of the schematic is, well, the top level.  There are blocks on
> it, and the blocks may or may not be attached, and by attached, I mean have
> signals between them.  Below each block is another schematic or an HDL file,
> or a "black box".  Etc.
> 
> You can create a hierarchy any number of blocks deep, with the last block
> you can push down through being either gates, a black box, or some HDL.
> 
> A schematic is nothing but a page with symbols on it, and connections.  A
> flow chart (done in schematics using libraries) is nothing but a bunch of
> flow chart symbols, and their attachments.  Each flow chart symbol is just
> like any other block, but it is used for a flow chart.  It is just a symbol
> with an underlying schematic, HDL or black box.

Ok, call me dense.  If you push down the hierarchy to lower level 
schematics, I can see there is no "synthesis" going on.  Eventually 
you'll end up with a schematic representation of a physical gate.  
However, if you push down to HDL you'll have a abstraction of that gate 
that is "synthesized" into the physical gate.

I'm not sure where the flowchart comes in.  Does it have a 
representation under it of a LUT/FF?  Or is the physical construction 
"synthesized" from the flowchart function.
> 
> > The mainframe logic designers I worked with ~ten years ago used flow
> > charts for the entire design.  The designs certainly were synthesized
> > (and simulated) from the flow charts.
> 
> Are you talking board level schematics, chip schematics or what?  I don't
> know the tool you are talking about.

Chip, module, board, frame, processor, complex. All schematics (or 
later, flowcharts).    

The tools were all internal.
 
> > > Ah, yes.  I understood that to mean that using schematics FOR that
> design
> > > was impractical because of the size of the design.
> >
> > That too.  The mainframes of the 70s-80's were designed using
> > schematics.  The logic diagrams filled carts for a single system unit.
> > Call me skeptical on designs this size.
> 
> That's why you use hierarchy.  The more abstract (to a point, of course) you
> can define the functions, the better your hierarchy.

Hierarchy only goes so far.  Sheer size can swamp the best thought out 
hierarchy. Eventually you need to flatten the hierarchy (placement, 
debug, etc.).  These things caught us many years ago, which is why VHDL 
was chosen, I suspect. 
 
> > For programmable logic, sure. I didn't mean PCI(-X) was an easy design.
> > 133MHz isn't fast at all for a custom design.
> >
> > I wuz just twitting ya' a tad. ;-)
> 
> > Yeah, well "twit" me after you've implemented a PCI-X design and see how
> "fast" it really is ;-)
> > I don't think I could have gotten anywhere with VHDL/FPGAs without the
> > HDL Analyst.  It took me a couple of months to figure out what language
> > constructs synthesized to the structure I wanted.
> 
> A fundamental gripe I have with synthesis tools.  They SHOULD provide a
> document that states EXACTLY what a construct gets synthesized to.  We used
> to do that when I wrote compilers, and I believe it's even more important to
> do for hardware...but for some reason, people like the "it's done by magic"
> philosophy.  Sigh.

Sure.  A design guide for synthesis would be a great idea.  I'm not 
sure how practical it would be though.  Certainly a "template" to 
structure document would be goodness. I'd think this would be the 
corporate jewels for a company like Synplicity and not likely to be 
published for mere customers.

OTOH, where it matters the design can be instantiated down to the 
primitives, which I realize is a vote for schematics.  I had to do this 
to get to the Virtex carry chains/SRL16s/blockrams. Other places I did 
it to force the structure I thought would be the fastest. In many 
places speed simply doesn't matter and the design can be as abstract as 
the designer cares to make it. 

----
  Keith

Article: 51579
Subject: Re: 200K gates FPGA for GPU
From: emanuel stiebler <emu@ecubics.com>
Date: Thu, 16 Jan 2003 13:15:47 -0700
Links: << >>  << T >>  << A >>
tsao wrote:
> Thanks,
> 
> tomorrow I'll bring my code to school
> to compile it using DK1 and see if it fits, and if everything go
> well, I'll post my Handle C source code somewhere.

Is sure interesting ...


>>If your 3D rendering pipeline is very roughly
>>
>>modeling
>>    lighting and transforms
>>        coordinate transforms and clipping
>>            triangles/quadrilaterals setup
>>                span rendering
>>                    shading, texturing, and Z-buffer check
>>
>>Then the last 3-4 stages, the data intensive ones, much in the integer
>>domain, can readily be done in an FPGA.  See for example
> 
> 
> Well, I thought those last stages still require floating point,
> like zbuffer and shading(color interpolation), and texture coordinates
> transforms. Anyway I'll see.

Not really.. After clipping, you are in the integer domain, and even
very small integers. (screen of 2048x2048 with subpixel resolution is
still less than 16 bit, colors are around 8 bit, etc.)
Largest is probably your z-buffer if you take 32 bits for it.
(and here is the problem for the divider also ;-)

cheers


Article: 51580
Subject: Re: 200K gates FPGA for GPU
From: emanuel stiebler <emu@ecubics.com>
Date: Thu, 16 Jan 2003 13:19:14 -0700
Links: << >>  << T >>  << A >>
Jan Gray wrote:

> Then the last 3-4 stages, the data intensive ones, much in the integer
> domain, can readily be done in an FPGA.  See for example
> http://www.fpgacpu.org/usenet/render.html, but note the date and the target
> FPGA (3K gates).  These days I would recommend rendering in bands or tiles
> and keeping the Z-buffer for the band/tile in block RAM.  Also, low res
> textures can probably fit in a block RAM texture store / texture cache.

As long as he doesn't do any filtering on the textures, I think to 
render in bands is easier and faster. Because you just touch every pixel 
only once, the pixel/zbuffer read/write pipeline is probably still the
slowest part of it.


Article: 51581
Subject: FPGA Express FSM state ordering
From: mschreiber75@yahoo.com (M Schreiber)
Date: 16 Jan 2003 12:46:46 -0800
Links: << >>  << T >>  << A >>
All,
  I was wondering if anybody knows how fpga express (3.5) orders the
states of the current_state register if I use enumerated data types
(using one-hot).  Like the following:
  
  type state_type is (IDLE, INIT, LOAD_1, LOAD_2, LOAD_3);
  signal CURRENT_STATE : state_type; 

after synthesis would CURRENT_STATE(0) be IDLE, CURRENT_STATE(1) be
INIT, CURRENT_STATE(2) be LOAD_1, CURRENT_STATE(3) be LOAD_2, and
CURRENT_STATE(4) be LOAD_3????

Or is it ordered the other way, or am I complete wrong???

Thanks in Advance,
  Mike

Article: 51582
Subject: Re: quality of software tools in general
From: Matt <matt@NOSPAMpeakfive.com>
Date: Thu, 16 Jan 2003 20:51:07 GMT
Links: << >>  << T >>  << A >>
rickman wrote:

> Sounds to me like you are a software person rather than a hardware
> designer, right?  

Let's just say the last time I designed hardware you could unsolder
parts using a plain old soldering iron and a solder sucker :) But you're
basically right.

> When you write HDL descriptions of hardware, you don't
> write the code thinking of the problem and let the tool generate its own
> hardware to solve it like is often done in software development.
> Although this works pretty well with most compilers, HDL synthesizers
> are not as well developed.  Normally a HDL developer will write his code
> thinking of the solution and use the HDL to describe what his solution
> should look like.  This is a very different process.
> 
> If you write HDL thinking of your solution then the tools work pretty
> well.  In that case your example above is not really practical since an
> FFT written in C would not translate well at all into an HDL as normally
> used.

This seems to be a hint to my answer. I'll rephrase the question. There
are companies that sell software that will take matlab or Handel-C and
turn it into fpgas.  So fft->fpga is possible.  What I want to do is
quantify how good that might be.  There's another thread running about
schematic entry vs vhdl that implies that vhdl is ok if it's used to
describe data flow as opposed to serial process flow. This implies that
the serial->data flow translation is not so good. How bad is it? If
writing serial code generates an fpga that's half as fast as writing
data flow then that's not bad. If it's a 1000 times slower and is 10
times the size then that's a serious problem. It's the usual assembly vs
C tradeoff.

Assuming the program is written using data flow, can a compiler do a
good job of place and route or is this another case where the user has
to get involved?  Considering that the graph theory anywhere near this
type of stuff is all NP I assume there is a problem. Since there are
tools that allow people to help with this I'm sure there's a loss of
efficiency by just letting the tool do everything. I just want to know
how much of a loss there is.

Matt

Article: 51583
Subject: SpartanII DLL lock issue
From: richard.coster@4rf.com (Richard Coster)
Date: 16 Jan 2003 13:44:47 -0800
Links: << >>  << T >>  << A >>
I am having problems locking the DLL on a SpartanII.  The DLL will not
lock on power up, or after configuration and will only lock after an
asynchronous reset.

The DLL is fed a 49MHz clock from a Cypress CY22393 programmable
clock, which itself is sourced from a crystal oscillator.  CLK0 is fed
back via a BUFG to the CLKFB pin.  The DLL is configured to divide by
2 with duty cycle correction enabled, STARTUP_WAIT to false.  The
CLKDV output feeds the design via another BUFG.  This configuration is
basically identical to XAPP132 Fig 9, except the CLKDV output is used
to drive the design.

The DLL will lock successfully if an asynchronous reset is provided
after power up or configuration.  Without the reset the DLL remains
unlocked.

I have checked the supply to the chip after configuration and there is
no apparent issue.

I have connected the RST input of the DLL to ground and it never
locks.

I have tried enabling the STARTUP_WAIT and setting DONE to transition
after lock, and it never finishes the start-up process.
 
I have removed all of the logic in the design, except the DLL, and it
locks every time after power up, configuration or reset.  Could there
be something in the logic stopping the DLL from locking?

Thanks in advance
Rich

Article: 51584
Subject: Re: adaptive filter with many zero input
From: "Patrick Mullarky" <pat@nwce.com>
Date: Thu, 16 Jan 2003 14:18:43 -0800
Links: << >>  << T >>  << A >>
A problem:  Pretty much by definition in an adaptive filter, you don't know
*where* in the 10 taps the non-zero elements and coefficients will appear!
You don't know in advance which elements or which coefficients will be null
at any given time. You actually do need one multiply per tap and, usually,
one multiply per coefficient update...though the latter can sometimes be
done with just shifts and adds...which is often slower...

You didn't mention your data rates. If you are not doing high-speed video or
multi-channel SONET channel equalization, and thus don't need a
fully-parallel design, then don't worry about which points are zeros!

For audio or low-speed video data-rates, a standard approach to this type of
FPGA application might be something like the following:

Use a single multiplier-accumulator element (MAC), and a state-machine, and
loop through the 10 taps after each sample. Then loop again updating the
coefficients. In a Xilinx Spartan IIE, for example, a ten-tap MAC loop takes
10 clocks plus a four clock MAC pipeline latency plus 3 clocks state-machine
overhead per pass. (16-bit samples and coefficients). That's only 17 clocks
total. Using a 50 MHz clock, two passes would only be 340 ns + 340ns per
input sample. With two multipliers, you could both MAC the filter and update
the coefficients in a single loop pass, cutting the processing time in half.

"Dongho" <dhan@ecel.ufl.edu> wrote in message
news:f6f40449.0301161156.291a8a6f@posting.google.com...
> Suppose 10 tap adaptive FIR filter and there are lots of zeros in
> input, say 2 out of 10. So I don't need 10 multipliers to muliply 10
> inputs and coefs because of many zero inputs(I need 2 multipliers).
> After calculating sum of inner product I need to update the coefs.
> How to save multipliers to implement adaptive FIR for this case?
> Thanks



Article: 51585
Subject: Re: SChematic design approach compared to VHDL entry approach
From: Ad Verschueren <ad.verschueren@NOxs4all.SPAMnl>
Date: Thu, 16 Jan 2003 23:22:22 +0100
Links: << >>  << T >>  << A >>
Assaf Sarfati wrote:

> bktan1974@netscape.net (John Tan) wrote in message news:<eb4dd21b.0301120804.6a2e6729@posting.google.com>...
> 
>>Hi, what is the merit & constraint of each of these design entry
>>methods
>>
>>- schematic design 
>>- VHDL 
>>
>>i have heard pple saying any changes in schematic entry, will cause
>>all timing to be changed and you got to check your timing again; is
>>this true ? ANd how about VHDL; is it really better?
>>
>>
>>I have last done a uni. project to implement a convolutional codec
>>using schematic entry method; and frankly i i can't imagine to program
>>the design in VHDL ...it's just too enormous the codes!
>>
> 
> I've been designing both H/W and S/W for far too many years (when I
> started, gates  came 4 to a package, which was called a "bug"...).
> I've used both schematics and HDL for designs of various sizes.
> 
> I am all for HDL, for the following reasons:


I cannot resist (as designer of the IDaSS tool) to counter your remarks ;-)
Just to indicate that (IMNSHO) good schematic tools which stop at the right
point with using schematics are a good alternative to HDL's. Feel free to
comment, of course - I can take criticism :-)

I put a link to the IDaSS homepage at the end ;-)


> *  Schematics can make the design structure and data flow more
> visible? sure, if your design flows data from one end to another.


Yep - good practice in drawing schematics.


> Control signals, however, are usually a rat's-nest, which rather
> spoils the pretty picture. For documenting the design, use a graphical
> editor (I use Visio), and draw only the interesting stuff; I don't
> have to bother with all the random signals which makes a schematic
> functional (even clocks and resets!).


In IDaSS, clock and reset are implied, no need to draw them. Also,
control and test signals from/to FSM's are not drawn but connected
by name from within the FSM description. You only see data buses and
RTL level blocks (which include the FSM's and sub-schematics) on the
schematics.


> *  Documenting your design: of course you can document a schematic
> design, but if you write in HDL you can (and I do) comment EVERYTHING:
> each port, each decision, why I did it this way and not that way. The
> comments are there near the design itself and not in a separate file
> which I have to open as well, and which I will probably be too lazy to
> update on every design change.


In IDaSS, you use a comment window to attach comments to blocks,
individual connectors, data buses, complete schematics etc. Comments
are also placed in all textual descriptions (FSM states, combinatorial
logic functions, data-to-control signal decoders etc.).


> *  Entering a design: I can type much faster than I can drag lines
> with a mouse. I can also create parameterized blocks and reuse them
> with no changes; a 4-bit counter and a 32-bit counter are the same.
> Will a schematic 4-bit counter be the same as a 32-bit counter?


In IDaSS, yes. If you tell a register block to increment or decrement,
it is a counter. This can be done continuously, under control of an
FSM (or more FSM's, as long as they don't send conflicting commands) or
controlled by decoding values on a databus.


> *  Maintaining a design: say you need an up/down counter which counts
> between 5 and 27. In your schematics it wil be a mess of gates and
> FFs;


As I indicated, a counter or an FSM or an ALU can be one block in IDaSS,
a few words of comments like 'counts between 5 and 27' suffice here.

> after you haven't touched this part of the design for a few
> months, you'll have to scratch your head quite a lot to understand
> what it's supposed to do (been there, done that). In an HDL design,
> even if it's uncommented, you can understand what it does in a glance.


With that last statement, I have to disagree completely - I'm not allowed
to show you a piece of Verilog which even the original designer does not
understand anymore (so they asked me to do a review - I've started drawing
schematics). Undocumented HDL is a capital offence.


> *  Navigating the design: most schematic tools have very poor search
> capabilities, compared to text editors. It's much easier to follow
> signals, especially as the display is much denser: I can view
> something like 100 lines of text at once, which can represent, for
> example, a state machine which will require many schematic pages.


If the HDL writers took care to keep signal names consistent, following
them can be done. It is not easy, though, when working on a multi-million
gate VLSI (described with several hundred HDL files).

For IDaSS, I've chosen very early on *not* to represent FSM's graphically.
Instead, I use a specially tailored language which directly names the
blocks to test and control and uses readable names for the commands to
send to the blocks. State transitions are also easily spotted and the
states themselves are named.


> *  Version Control: you can save schematics in a VCS; but how do you
> compare versions? once, long ago, I've thought of writing an
> application to read graphic representation of a schematic (using
> HP-GL, then used for most printing), and then overalying the output
> graphics on a display. After some thought, I gave it up and returned
> to the old method of overlaying the schematics on a light table - very
> hard work.
> 
> In a text-based design, you can very easily compare version: aha! I've
> added a pipeline register here! so THAT is the bug! all in a few
> minutes.


I have to agree - IDaSS is lacking version control. Is on the to-do list...
In our design team at work (where we use 'raw' Verilog, not IDaSS :-( ),
we *have* to use a version management tool - we would be absolutely lost
without it.


> * Simulation & verification: if your design is a schematic, how do you
> simulate?


Hah - that is probably IDaSS's strongest point: the simulator is integrated
with the 'design entry' tool. The 'SUD' ('System Under Design') is being
simulated while it is built. The schematics are alive, and you have access
to the state (and not only for inspection, also for changing it) at all
times. You can clock step the simulation, change values in registers and see
results of combinatorial logic immediately change, run for a specific
simulation time or number of clocks...

> usually you draw waveforms (or the text equivalent of
> writing test-vectors) - more of the same hard work. When your design
> is HDL, you can create an interactive test-bench (with the design,
> sadly not with you)


The 'I' in IDaSS stands for Interactive - and the interaction is indeed
with the user (although you can easily create 'old fashioned' test
benches if you want, there is even a special block which allows you
to write test programs for execution in connection with the RTL design -
more than one of these blocks can be used, they allow interrupts to be
modelled, etc. etc.).

> and automate the whole process; run it at night
> and in the morning you see, before your first coffee, if it worked or
> not.


Yup - and then you may have to dig into millions of clock cycles of data
to find where it went wrong - ooops, did not log that signal :-(
I know that drill and I have to live with it... Regression testing
has its merits and must be done - should be first time right, though.


> All that said, I still belive that a person who has schematic design
> experience will usually create better HDL designs, the same way that a
> programmer who has Assembly code experience will usually write better
> high-level language code.


I absolutely, completely agree - I taught at University, and made sure
the students could write assembly as well as 'high level' C (oh, and
they designed working microprocessors with IDaSS in their first year).

OK, the promised link to the 'Interactive Design and Simulation System'
(IDaSS) homepage:

http://www.xs4all.nl/~averschu/idass

Greetings and have fun,

Ad Verschueren


Article: 51586
Subject: Re: Support for older Virtex
From: Steve Lass <lass@xilinx.com>
Date: Thu, 16 Jan 2003 15:43:33 -0700
Links: << >>  << T >>  << A >>
David,

Virtex was never supported in WebPACK.  The first Virtex family supported
in the WebPACK was VirtexE.  You will  need to purchase ISE BaseX to do
a XCV50.

Steve

Langmann wrote:

> Hi,
>
> I was under the impression (from a previous post) that support would be
> available for older devices (such as the XCV50PQ240, for example) in the
> free or low cost software that Xilinx provides on the Web. From what I see
> in ISE 5.1 this is not the case.
>
> Does anyone have any information on this?
>
> Thanks,
> David


Article: 51587
Subject: Re: Multiple FPGA-boards integration issues
From: prashantj@usa.net (Prashant)
Date: 16 Jan 2003 14:49:10 -0800
Links: << >>  << T >>  << A >>
> While a design spread over multiple chips are much harder to simulate,
> it might be cheaper to do a board with everything in one chip.
> 
> Rene

I would rather use a single device. But there are many reasons which
make that difficult. The design size is not small enough to meet the
timing requirement and fit in a single device as of now. Also, two
different companies could be working on the project with neither
wanting to give out IP (for good reasons). In such a situation,
multiple boards are inevitable. Also one of the boards may have an
ASIC on it.

Thanks,
Prashant

Article: 51588
Subject: Re: Support for older Virtex
From: Kevin Brace <kev3inbrac5eusen7et@ho9tmail.c1om>
Date: Thu, 16 Jan 2003 17:22:26 -0600
Links: << >>  << T >>  << A >>
Steve,

Since Virtex-E up to 300K system gates is supported by ISE WebPACK, why
not Xilinx support Virtex up to 300K system gates in ISE WebPACK?


Kevin Brace (If someone wants to respond to what I wrote, I prefer if
you will do so within the newsgroup.)



Steve Lass wrote:
> 
> David,
> 
> Virtex was never supported in WebPACK.  The first Virtex family supported
> in the WebPACK was VirtexE.  You will  need to purchase ISE BaseX to do
> a XCV50.
> 
> Steve
>

Article: 51589
Subject: Re: Support for older Virtex
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Thu, 16 Jan 2003 23:34:05 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <b07ej5$d5t$1@newsreader.mailgate.org>,
Kevin Brace  <kev3inbrac5eusen7et@ho9tmail.c1om> wrote:
>Steve,
>
>Since Virtex-E up to 300K system gates is supported by ISE WebPACK, why
>not Xilinx support Virtex up to 300K system gates in ISE WebPACK?

I thought Spartan II was in many ways compatable with the Virtex?
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 51590
Subject: Re: Schematic design approach compared to VHDL entry approach
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 16 Jan 2003 16:33:38 -0800
Links: << >>  << T >>  << A >>
I wrote:
> Have you seen such a manual for a C compiler?

"Austin Franklin" <austin@da98rkroom.com> writes:
> Er, yes.

Where?

Article: 51591
Subject: Re: Student development board
From: wv9557@yahoo.com (Will)
Date: 16 Jan 2003 17:30:53 -0800
Links: << >>  << T >>  << A >>
"David" <gretzteam@hotmail.com> wrote in message news:<gVlT9.10113$3u5.32039@weber.videotron.net>...
> Hi,
> Does anyone know what is the best choice for an fpga developement kit?
> Altera offers this kit for University student :
> http://www.altera.com/education/univ/kits/unv-kits.html
> I wonder if there are other supplier of boards like this (could be Xilinx
> too) that could compete with this. Are there third party manufacturer that
> are worth considering?
> Thanks
> David

what's the fun in buying a kit :)?
The following board is inspired by the XESS XCS series board, and
uses an XC4000 part.

http://www.geocities.com/wv9557/fpga_pic.jpg

Article: 51592
Subject: Re: Bug in Quartus2 Web 2.2
From: nospam@aol.com
Date: Thu, 16 Jan 2003 20:59:43 -0500
Links: << >>  << T >>  << A >>
My last attempt at getting Altera support wound up with their
answering me with blanks.  That's right, BLANK responses.  And I don't
believe they read the messages either, based on previous answers.

I have turned to Xilinx now, and must say that their (free) web-based
software and readily available parts (Digikey) beats Altera hands
down.  Not to mention that I have seen Xilinx's presence on this
newsgroup!  If Altera is here, they are well-hidden.



On Mon, 13 Jan 2003 14:20:04 +0100, "Matjaz Finc"
<matjaz.finc@fe.uni-lj.si> wrote:

>My experience:
>
>The Altera MySupport is useless, often slow and above all inapropriate in my
>experience. Looks like it's there just for marketing purposes - to be
>mentioned as superb on-line support for potential customers. When you (me)
>need help, usualy you get riduculous short answers that show they don't even
>try to read your whole message, not to mention answering it thoroughly and
>exactly. I often find the solution to my problems in this newsgroup (really
>prompt response!) or on my own before I get any info from MySupport that
>makes any sense.
>
>Regards,
>Matjaz
>
>"Austin Lesea" <austin.lesea@xilinx.com> wrote in message
>news:3E1C4F1E.1BD53CBD@xilinx.com...
>> Rene,
>>
>> Please, do not discourage people from using internet based support tools.
>>
>> I can not speak for Altera (obviously), but email and web-based support is
>> becoming a major means of asking and answering customer questions in a
>timely
>> fashion.
>>
>> The fact that Altera has someone who watches the comp.arch.fpga forum
>indicates
>> that they really do care about customer service, and 'caught' your inquiry
>in this
>> forum.
>>
>> Our hotline group would prefer that a case gets entered into their system,
>as they
>> will answer it quicker that way.  But for those that wish to get other
>opinions,
>> this newsgroup is also valuable.
>>
>> I know that Xilinx takes this all very seriously, and watches response
>time vs.
>> how the case is entered to maintain quality of service target levels.
>>
>>
>>
>> Austin
>>
>> Rene Tschaggelar wrote:
>>
>> > Thanks for the quick reply.
>> > Amazingly quicker than the mentioned 'MySupport',
>> > but then again not - proves my point.
>> >
>> > Rene
>> >
>> > Subroto Datta wrote:
>> > > Rene,
>> > >    A fix for this problem is under development. More details about its
>> > > availability will be posted as soon as the fix is tested and released
>in the
>> > > very near future (no later than end of this week). Thanks for bringing
>this
>> > > problem to our attention.
>> > >
>> > > - Subroto Datta
>> > > Altera Corporation
>> > >
>> > > "Rene Tschaggelar" <tschaggelar@dplanet.ch> wrote in message
>> > > news:3E1B4021.2090607@dplanet.ch...
>> > >
>> > >>I found a bug in quartus2 Web V2.2.
>> > >>When tring to place legacy components in schematic editor,
>> > >>such as the 74165b shiftregister, its connectors are off
>> > >>grid. This makes it somewhat hard to connect.
>> > >>
>> > >>Did anyone figure a workaround ?
>> > >>
>> > >>Their support is useless : login(!), place a question,
>> > >>relogin(!) to get a reply, so I didn't ask there.
>>
>


Article: 51593
Subject: Re: Schematic design approach compared to VHDL entry approach
From: Ray Andraka <ray@andraka.com>
Date: Fri, 17 Jan 2003 03:00:38 GMT
Links: << >>  << T >>  << A >>
I think I disagree with you here.  One shouldn't need to flatten the hierarchy for
debug nor for placement.  For placement, RLOCs are hierarchical...use them for
hierarchical floorplanning.  We do this, and typically only spend a day or two on
some quite extensively floorplanned designs.  I really ought to put a floorplan
gallery on my website to point out what I am talking about.  If you've ever seen
one of my design floorplans you'd immediately recognize that it is far different
that what you usually see in floorplans.  Hierarchy in the floorplanning saves
gobs of time (I shudder to think how long it would have taken to floorplan a
recent full XC2V6000 design if it wasn't done hierarchically.  With hierarchy, I
spent less than 20 hours in floorplanning including the time to put hte RLOCs in
the code (the lower levels of the code were already RLOCed and are reused
code).    For debug, I generally use lots of simulation and a little bit of extra
hooks added to the design.  Again, I couldn't imagine trying to wade through a
flattened design in that scenario.

Frankly, I'm not sure how size swamps hierarchy.  In fact, I think the larger the
design the more necessary hierarchy is to keep the design problem sane.  Hierarchy
lets you divide and conquer in the design as well as in the verification.

"Keith R. Williams" wrote:

> Hierarchy only goes so far.  Sheer size can swamp the best thought out
> hierarchy. Eventually you need to flatten the hierarchy (placement,
> debug, etc.).  These things caught us many years ago, which is why VHDL
> was chosen, I suspect.
>

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

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



Article: 51594
Subject: Re: need pointers to FPGA software & download hardware
From: 2Penny <lw_rogers@sbcglobal.net>
Date: Fri, 17 Jan 2003 03:35:45 GMT
Links: << >>  << T >>  << A >>
Gentlemen:

I used ABEL from "Digital I/O" (made available to educational
institutions at reduced cost).  I found out the cost of this
software to noneducational institutions is a couple of hundred
percent more than what the college paid for it.  I used the
PLDs made available to the students (18CV8s).

The reason I was originally interested in this has to do
with RadHard FPGAs that can be programmed to be CPUs as
well as producing a more minimized design of the board
I had been working on.  Anyway, this all has some
relevance to space applications and Minimal Instruction
Set Computers (apparently the next generation of CPUs
will be designed to minimize the number of transistors
without compromising performance).

Thanks for the input,

2Penny

rickman wrote:
> 2Penny wrote:
> 
>>Gentlement:
>>
>>I've built a small computer board for a small local college (mostly
>>from one of the professor's designs and partly from designs in the
>>book).  The machine uses PLDs in several places and I figured I could
>>simplify the board some (and improve by skills) by (learning about and)
>>using FPGAs, but I don't know where to get the initial software or
>>download equipment.
> 
> 
> If you want to simplify the board, you might do better using a CPLD. 
> FPGAs can be used, but they are not ready for operation at power up. 
> They must be configured.  Most of the CPLDs are EEPROM or Flash based
> and once programmed, will operate immediately on power up.  The CPLDs
> are mostly organized as multiple PLDs with extra interconnections.  Can
> you tell us what PLDs the board currently uses?  
> 


Article: 51595
Subject: Re: How to add pins in ISE 4.2
From: amit_ashara@hotmail.com (Amit)
Date: 16 Jan 2003 19:56:42 -0800
Links: << >>  << T >>  << A >>
Hi Kuan,

 When you add a pin in Xilinx FPGA Editor it asks for a name in a
field called "component name". There by default it is "$Comp0". You
can edit the name and give it another one but be sure to add the "$"
sign.

Regards
Amit Ashara

Kuan Zhou <zhouk@rpi.edu> wrote in message news:<Pine.SOL.3.96.1030116102633.19960B-100000@vcmr-86.server.rpi.edu>...
> Hi,
>    I have solved it.But the strange thing is: when I add a pin named A1 in
> the schematic design,the pin is not shown as A1 in the FPGA editor.The
> name is changed to xlxn_2 or something similar.Do you have any way to
> solve it?
> 
>    Thank you very much!
> 
> sincerely
> -------------
> Kuan Zhou
> ECSE department
> 
> 
> On 16 Jan 2003, Amit wrote:
> 
> > Hi Kuan,
> > 
> >  Which schematic tool are using in the ISE 4.2. For e.g. is it the
> > FPGA editor, etc..
> > 
> > Regards
> > Amit
> > 
> > Kuan Zhou <zhouk@rpi.edu> wrote in message news:<Pine.SOL.3.96.1030114211435.25313A-100000@vcmr-86.server.rpi.edu>...
> > > Hi,
> > >    I am using ISE 4.2 student version.But I can not find output pad in the 
> > > schematic tools.Does any one know how to add pins in the schematic design?
> > > The help says you can find "add pins" from the Add menu,but I can not find
> > > it.
> > > 
> > >    Thank you very much!
> > > 
> > > sincerely
> > > -------------
> > > Kuan Zhou
> > > ECSE department
> > 
> >

Article: 51596
Subject: Re: SChematic design approach compared to VHDL entry approach
From: johnjakson@yahoo.com (john jakson)
Date: 16 Jan 2003 20:07:51 -0800
Links: << >>  << T >>  << A >>
"Austin Franklin" <austin@da98rkroom.com> wrote in message news:<v2dvkemrfapa1b@corp.supernews.com>...
> > SW engineers ...SW engineers ....SW engineers ....
> 
> You are making a GROSS assumption here, that people who write software ARE
> in fact engineers.  Most are simply NOT.  In fact, I would say very few are.
> 
> Austin

I was being respectful here, at least I would say so for most of the
SW engineers at the famous EDA companies. As for the mass of folks
that write in VB or any other script langs, well I don't usually come
across them.

Article: 51597
Subject: Re: Xilinx Constraint Problem
From: amit_ashara@hotmail.com (Amit)
Date: 16 Jan 2003 20:11:45 -0800
Links: << >>  << T >>  << A >>
Hi All,

 I Agree with Falk Brunner's suggestion of routing the clock from a
normal I/O pin to a IBUF and BUFG so that it can take the global
routing resource. But do not try to put an IBUFG as it will be locked
to a clock pad. Also to stabilise the clock try using a DLL or a DCM
alongwith it. In this case the clock to the internal logic will be a
very stable clock.

Regards,
Amit

"Falk Brunner" <Falk.Brunner@gmx.de> wrote in message news:<b06vfj$mcpnb$1@ID-84877.news.dfncis.de>...
> "rickman" <spamgoeshere4@yahoo.com> schrieb im Newsbeitrag
> news:3E26F6D3.18D62D71@yahoo.com...
> 
> Agree.
> 
> A clock should only be routed on a global clock net. Yes, you can also use
> local routing, but this is the high art for the guys that know what they are
> doing.
> But In this case, the is a possibility to workaround this problem.
> Instanciate a IBUF (normal input buffer) and a BUFG (global clock buffer).
> This way, you can get your clock signal into you FPGA via a normal IO pin
> and route it internaly to the global clock buffer. The only thing you will
> not ave compared to the dedicated clock input is, the defined timing
> relation between the clock on the input pin and the clock on your global
> clock net, means, the skew between them is more of less random within some
> limits. But this wont be a problem if you have no control line comming into
> you FPGA with a fixed timing relation to your clock.

Article: 51598
Subject: Re: Xilinx Constraint Problem
From: Ray Andraka <ray@andraka.com>
Date: Fri, 17 Jan 2003 04:50:52 GMT
Links: << >>  << T >>  << A >>
I concur with bringing the clock to a bufg (not an ibufg) once it is in the chip.  The DLL won't clean up
a clock with jitter, the best it will do is restore symmetry to the duty cycle.  If you have external
signals also sync'ed to the clock, you are in for a possibly rough ride for sampling those signals as the
clock skew is no longer tightly controlled.  If you had a clock out from the FPGA you could use that with
a DLL to clean up the clock timing, but then you'd be back in the same situation of having to respin the
board.

Amit wrote:

> Hi All,
>
>  I Agree with Falk Brunner's suggestion of routing the clock from a
> normal I/O pin to a IBUF and BUFG so that it can take the global
> routing resource. But do not try to put an IBUFG as it will be locked
> to a clock pad. Also to stabilise the clock try using a DLL or a DCM
> alongwith it. In this case the clock to the internal logic will be a
> very stable clock.
>
> Regards,
> Amit
>
> "Falk Brunner" <Falk.Brunner@gmx.de> wrote in message news:<b06vfj$mcpnb$1@ID-84877.news.dfncis.de>...
> > "rickman" <spamgoeshere4@yahoo.com> schrieb im Newsbeitrag
> > news:3E26F6D3.18D62D71@yahoo.com...
> >
> > Agree.
> >
> > A clock should only be routed on a global clock net. Yes, you can also use
> > local routing, but this is the high art for the guys that know what they are
> > doing.
> > But In this case, the is a possibility to workaround this problem.
> > Instanciate a IBUF (normal input buffer) and a BUFG (global clock buffer).
> > This way, you can get your clock signal into you FPGA via a normal IO pin
> > and route it internaly to the global clock buffer. The only thing you will
> > not ave compared to the dedicated clock input is, the defined timing
> > relation between the clock on the input pin and the clock on your global
> > clock net, means, the skew between them is more of less random within some
> > limits. But this wont be a problem if you have no control line comming into
> > you FPGA with a fixed timing relation to your clock.

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

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



Article: 51599
Subject: Re: quality of software tools in general
From: rickman <spamgoeshere4@yahoo.com>
Date: Fri, 17 Jan 2003 00:29:18 -0500
Links: << >>  << T >>  << A >>
Matt wrote:
> 
> This seems to be a hint to my answer. I'll rephrase the question. There
> are companies that sell software that will take matlab or Handel-C and
> turn it into fpgas.  So fft->fpga is possible.  What I want to do is
> quantify how good that might be.  There's another thread running about
> schematic entry vs vhdl that implies that vhdl is ok if it's used to
> describe data flow as opposed to serial process flow. This implies that
> the serial->data flow translation is not so good. How bad is it? If
> writing serial code generates an fpga that's half as fast as writing
> data flow then that's not bad. If it's a 1000 times slower and is 10
> times the size then that's a serious problem. It's the usual assembly vs
> C tradeoff.
> 
> Assuming the program is written using data flow, can a compiler do a
> good job of place and route or is this another case where the user has
> to get involved?  Considering that the graph theory anywhere near this
> type of stuff is all NP I assume there is a problem. Since there are
> tools that allow people to help with this I'm sure there's a loss of
> efficiency by just letting the tool do everything. I just want to know
> how much of a loss there is.

I have never worked with Handel-C before.  But in VHDL and Verilog you
need the concept of concurrency in order to describe hardware. 
Conventional C programs are not normally written in this style and so do
not translate into hardware well or possibly at all.  I know that
Handel-C is not the same as conventional C.  If it were they would just
use that.  

I guess my question to you is, was the FFT written in C or Handel-C?  If
you know of vendors who sell these tools, then you should be asking them
to show you some examples of code and how well it translates into
hardware.  Then ask them about your application.  If you can provide
code to them, they should be willing to run it through the tools for you
as a sales demo.  They might even be able to demo the result on an FPGA
eval board.  An FFT really doesn't require lots of hardware.  But it
depends entirely on how it is implemented (as specified in the code)
which is what HDLs are all about.  

-- 

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



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