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 142425

Article: 142425
Subject: Re: Spartan-6 Boards - Your Wish List
From: John Adair <g1@enterpoint.co.uk>
Date: Mon, 10 Aug 2009 14:05:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
I'll have a look at this one.

John Adair
Enterpoint Ltd.

On 10 Aug, 21:03, "Pete Fraser" <pfra...@covad.net> wrote:
> "John Adair" <g...@enterpoint.co.uk> wrote in message
>
> news:d4baa37f-f871-4143-9711-23ce3d444009@g1g2000vbr.googlegroups.com...
>
> > Your chance to have input to what we bring to market as Spartan-6
> > products.
>
> I do a lot of video algorithm development.
> DVI (dual-link) I/O would be great.
> HDMI and DisplayPort would be a nice addition.
>
> Pete


Article: 142426
Subject: Re: delta-signa DAC with FPGA
From: "langwadt@fonz.dk" <langwadt@fonz.dk>
Date: Mon, 10 Aug 2009 14:47:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 10 Aug., 14:38, Antti <Antti.Luk...@googlemail.com> wrote:
> Hi
>
> it seems that i may have lost all my skills of using google :(
> as I havent found any ready to use HDL for for DS DAC
> with higher order than 1
>
> only research papers, or then commercial cores, but absolutly
> no HDL sources. this cant be true?
>
> or is there some magic reason why all online DS DAC code
> is first order only? so far i have failed to figure out what the
> reason could be.
>
> Antti

It's been a long time since I last worked with DSMs, second order is
simple enough
that might be why you can't find any? third order and higher get a bit
more tricky to
implement because you can't just add more stages and keep it stable so
you need a
different structure

even second order is potentially unstable, afair usually with close to
fullscale inputs

-Lasse

Article: 142427
Subject: Re: Spartan-6 Boards - Your Wish List
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 10 Aug 2009 22:30:59 +0000 (UTC)
Links: << >>  << T >>  << A >>
John Adair <g1@enterpoint.co.uk> wrote:
> Yes if you can hit a combination that suits a particular school you
> could make it worth doing. That's only every really happened though
> with a couple of boards in the market as far as I know. If you look at
> the sales of Spartan-3 boards apart from those boards the sales are
> relatively low and not in the critical mass area to make that all
> work. However if you have particular suggestions I am open to looking
> at them and pricing the cost of adding them to a product.

I have no current connection to a school CS/EE department.

I do remember doing TTL based projects in CS/EE lab courses,
but I understand that they don't do that anymore, but use
simulation instead.  

At FCCM95 I was part of a discussion that FPGA companies should
offer free software to help people get started in FPGA work,
especially for introductory CS/EE classes.  In years past, the
computer industry bought enough TTL chips to keep quantities
up and prices low.  It seems that many are still available for
low prices, but maybe not so much longer.  

I am not sure what you would need to do to get a school to
start using a board, but I believe it would be better than
learning only through simulation.

-- glen

Article: 142428
Subject: algorithm implementation in IC
From: jogging <joggingsong@gmail.com>
Date: Tue, 11 Aug 2009 02:01:39 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,all
   I'm not a FPGA engineer or IC designer.
In fact, I'm a DSP engineer. So I have little
knowledge about FPGA and IC design. I am
wandering the way that a algorithm is implemented
in IC. In IC desgin, the first step is algorithm
design and C model implementation. Do algorithm
engineers need to know FPGA implementation details
In this step? If they have no idea about FPGA
implementation, the algorithm may not be implemented
efficiently in FPGA. When algorithm engineers know FPGA
well they choose the efficent methods which can
minimize area and power consumption. If FPGA engineers
know little about algorithms, they can't make trade off
between algorithm complexity and implementation efficiency.
There is a gap between algorithm design and FPGA implementation.
In IC industry, how is this problem solved?

Best Regards
Jogging

Article: 142429
Subject: Re: algorithm implementation in IC
From: Jon <jon@beniston.com>
Date: Tue, 11 Aug 2009 03:10:21 -0700 (PDT)
Links: << >>  << T >>  << A >>
> There is a gap between algorithm design and FPGA implementation.
> In IC industry, how is this problem solved?

You're not much of an "algorithm engineer" if you don't know how
something will be implemented.

Jon

Article: 142430
Subject: Re: Spartan-6 Boards - Your Wish List
From: Herbert Kleebauer <klee@unibwm.de>
Date: Tue, 11 Aug 2009 14:19:23 +0200
Links: << >>  << T >>  << A >>
glen herrmannsfeldt wrote:
> John Adair <g1@enterpoint.co.uk> wrote:

> > Yes if you can hit a combination that suits a particular school you
> > could make it worth doing. That's only every really happened though
> > with a couple of boards in the market as far as I know. If you look at
> > the sales of Spartan-3 boards apart from those boards the sales are
> > relatively low and not in the critical mass area to make that all
> > work. However if you have particular suggestions I am open to looking
> > at them and pricing the cost of adding them to a product.
 
> I am not sure what you would need to do to get a school to
> start using a board, but I believe it would be better than
> learning only through simulation.

We use the DARNAW1 board in a beginners course (implementation
of a 16 bit minimal processor in a total time of about 12 hours).
But you don't need a board for every student but only one for
the class (downloading the bit file is just the final test).

http://www.bitlib.de/pub/mproz/mproz2a.pdf
http://www.bitlib.de/pub/mproz/mproz3_e.pdf

But the current Xilinx software is not in a state (no back annotation
of the simulation results into the schematics) that we can use it
for more than a trivial design (we use schematics entry, no VHDL).
Therefore we still have to use the old DOS Viewlogic/Xilinx software
and a XC3195 FPGA for the design of a more powerful 16 bit CPU in
a later laboratory course.

http://www.bitlib.de/pub/xproz/


Article: 142431
Subject: Re: algorithm implementation in IC
From: Kolja <ksulimma@googlemail.com>
Date: Tue, 11 Aug 2009 06:24:40 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 11 Aug., 11:01, jogging <joggings...@gmail.com> wrote:
>  In IC desgin, the first step is algorithm
> design and C model implementation.
I always wondered why anyone would want to model the algorithms in
C nowadays. There are so many nice modern languages around with
object orientation, etc.
Prototyping should be much quicker and less error prone with any of
these
compared to C.

> Do algorithm
> engineers need to know FPGA implementation details
> In this step?

I think it is sufficient to have some information on the cost of
various
operations, like the number and size of RAMs, Multipliers, FIFOs etc.
And some informations on the relativ speed of these operations.


Kolja Sulimma


Article: 142432
Subject: DDR2 Controllers: Bursting to Odd Addresses
From: jc <jcappello@optimal-design.com>
Date: Tue, 11 Aug 2009 06:26:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

If anyone can shed some clues on our dilemma with using odd starting
addresses with our DDR2 controller, please write.

We have been using a MIG 1.6-generated DDR2 controller successfully
for a couple of years until we recently started using "odd" starting
addresses. By "odd" we are referring to those addresses that aren't
bound by the burst length. For example, we are using a burst length of
4. So we have no problems whenever we start off with the two LSB's of
the address as "00." But if those two LSB's are 1, 2, or 3. It doesn't
work.

We were advised that during write bursts, the DDR2 controller ignores
the two LSB's, so we have to use masking for write bursts and align
the data properly. For read bursts, we were told that the controller
does NOT ignore the LSB's, that we can use the explicit address.

So, to perform a burst of 32-bit data {1,2,3,4} into memory starting
at address 1, we would do the following sequence (our data bus size is
64 bits):

CYCLE 1
DATA = X on upper 32 bits, 1 on lower 32 bits (X=don't care)
MASK = 0xF0 (Mask upper 32 bits)
ADDR = 0x1
assert addr and data strobes

CYCLE 2
DATA = 2, 3
MASK = 0x00 (no mask)
ADDR = X
assert data strobe

CYCLE 3
DATA = 4, X
MASK = 0x0F (mask lower 32 bits)
ADDR = 0x5 (increment initial addr by 4)
assert addr and data strobe

CYCLE 4
DATA = X, X
MASK = 0xFF (mask all data bits)
ADDR = X
assert data strobe

Do you agree with the above sequence? If not, I'd like to hear what
has worked for you.
Thank you for any clues.
John

Article: 142433
Subject: Re: Spartan-6 Boards - Your Wish List
From: John Adair <g1@enterpoint.co.uk>
Date: Tue, 11 Aug 2009 07:36:09 -0700 (PDT)
Links: << >>  << T >>  << A >>
Herbert

I hadn't seen these labs before but it's good to see that you are
doing exactly what we expected of Darnaw1 - low tech carrier boards
with the Darnaw1 on top with the FPGA and memory features. Did you
hand etch the PCB as well?

The Darnaw1 is getting a mid-life update with slightly bigger SPI
Flash coming later this year but we will be continuing the range with
Darnaw2 as well. For those in the know this was originally scheduled
to be  V4-FX12 based product but as we slipped on getting this one out
it is almost certainly going morph into a Spartan-6 product with
similar features to Darnaw1. It should be pin compatible(PGA pin
usage) as well. That is one my main criteria to the team on this
product. It will have probably a DDR3 dram instead of the SDRAM on
Darnaw1 but otherwise just bigger and faster resources.

There other easy to use parts coming as well. The Craignell2 family
may expand with a larger pincount version assuming we don't have
Spartan-6 based Craignell3 there before it. Craignell3 will fill the
gaps better the Darnaw products and existing Craignell products.

Developing our monster board - Merrick1 has been slowing down the
releases of a pile of new products. Now that is out in the wild the
team working hard to bring those releases to the market and we should
have a lot of new things Q3/4 this year for all of you.

John Adair
Enterpoint Ltd.


On 11 Aug, 13:19, Herbert Kleebauer <k...@unibwm.de> wrote:
> glen herrmannsfeldt wrote:
> > John Adair <g...@enterpoint.co.uk> wrote:
> > > Yes if you can hit a combination that suits a particular school you
> > > could make it worth doing. That's only every really happened though
> > > with a couple of boards in the market as far as I know. If you look at
> > > the sales of Spartan-3 boards apart from those boards the sales are
> > > relatively low and not in the critical mass area to make that all
> > > work. However if you have particular suggestions I am open to looking
> > > at them and pricing the cost of adding them to a product.
> > I am not sure what you would need to do to get a school to
> > start using a board, but I believe it would be better than
> > learning only through simulation.
>
> We use the DARNAW1 board in a beginners course (implementation
> of a 16 bit minimal processor in a total time of about 12 hours).
> But you don't need a board for every student but only one for
> the class (downloading the bit file is just the final test).
>
> http://www.bitlib.de/pub/mproz/mproz2a.pdfhttp://www.bitlib.de/pub/mproz/mproz3_e.pdf
>
> But the current Xilinx software is not in a state (no back annotation
> of the simulation results into the schematics) that we can use it
> for more than a trivial design (we use schematics entry, no VHDL).
> Therefore we still have to use the old DOS Viewlogic/Xilinx software
> and a XC3195 FPGA for the design of a more powerful 16 bit CPU in
> a later laboratory course.
>
> http://www.bitlib.de/pub/xproz/


Article: 142434
Subject: Re: DDR2 Controllers: Bursting to Odd Addresses
From: "maxascent" <maxascent@yahoo.co.uk>
Date: Tue, 11 Aug 2009 10:38:12 -0500
Links: << >>  << T >>  << A >>
For a DDR2 memory using a seq burst type the order of the burst will depend
on the lower bits of the column addr. 

Addr LSB = 00 Burst = 0,1,2,3
Addr LSB = 01 Burst = 1,2,3,0
Addr LSB = 10 Burst = 2,3,0,1
Addr LSB = 11 Burst = 3,0,1,2

So if you are starting from an addr with LSB that are not 00 the burst
will wrap around so you will need to use a mask. I wouldn't of thought the
MIG controller will do anything clever to apply the mask for you.

Jon

Article: 142435
Subject: Re: DDR2 Controllers: Bursting to Odd Addresses
From: jc <jcappello@optimal-design.com>
Date: Tue, 11 Aug 2009 09:50:00 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 11, 11:38=A0am, "maxascent" <maxasc...@yahoo.co.uk> wrote:
> For a DDR2 memory using a seq burst type the order of the burst will depe=
nd
> on the lower bits of the column addr.
>
> Addr LSB =3D 00 Burst =3D 0,1,2,3
> Addr LSB =3D 01 Burst =3D 1,2,3,0
> Addr LSB =3D 10 Burst =3D 2,3,0,1
> Addr LSB =3D 11 Burst =3D 3,0,1,2
>
> So if you are starting from an addr with LSB that are not 00 the burst
> will wrap around so you will need to use a mask. I wouldn't of thought th=
e
> MIG controller will do anything clever to apply the mask for you.
>
> Jon

Thanks for responding, Jon. So is your interpretation that the DDR2
control does look at the LSB's? In which case this would make the
write burst I described incompatible because I am using an address of
0x5 instead of 0x4. I would told the LSB's would be don't care in the
start address during write bursts.

Article: 142436
Subject: Re: Spartan-6 Boards - Your Wish List
From: Marko Zec <zec@fer.hr>
Date: Tue, 11 Aug 2009 17:12:54 +0000 (UTC)
Links: << >>  << T >>  << A >>
John Adair <g1@enterpoint.co.uk> wrote:
...
> There other easy to use parts coming as well. The Craignell2 family
> may expand with a larger pincount version assuming we don't have
> Spartan-6 based Craignell3 there before it. Craignell3 will fill the
> gaps better the Darnaw products and existing Craignell products.

+1 vote here for Spartan-6 based Craignell3 with a large DDR2 / DDR3
in say 80 pin version but still pluggable into 40 DIL sockets for
legacy applications...

Marko

Article: 142437
Subject: Re: Spartan-6 Boards - Your Wish List
From: Andy Peters <google@latke.net>
Date: Tue, 11 Aug 2009 10:47:47 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 9, 5:44=A0am, John Adair <g...@enterpoint.co.uk> wrote:
> Guys and Girls
>
> Your chance to have input to what we bring to market as Spartan-6
> products.
>
> We have several release candidates nearly ready now but we can still
> add or modify features and I am interested in features you would all
> like to have in these boards either based on things we hve done before
> in our product range or even new features you would like to see.
>
> So go ahead and let us know what you want.

I am sure a lot of audio types would like a daughter card with
reasonable I2S-connected ADC and DAC devices.

-a

Article: 142438
Subject: Re: Spartan-6 Boards - Your Wish List
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 11 Aug 2009 18:14:32 +0000 (UTC)
Links: << >>  << T >>  << A >>
Herbert Kleebauer <klee@unibwm.de> wrote:
< glen herrmannsfeldt wrote:
 
<> I am not sure what you would need to do to get a school to
<> start using a board, but I believe it would be better than
<> learning only through simulation.
 
< We use the DARNAW1 board in a beginners course (implementation
< of a 16 bit minimal processor in a total time of about 12 hours).
< But you don't need a board for every student but only one for
< the class (downloading the bit file is just the final test).

The frosh classes that I had consisted of a one term lecture class
followed by a one term lab.  That was 30 years ago, so things might
have changed over time.  Even so, the lecture class followed 
(in the subsequent term) by a lab seems to work well.

The lecture demonstrations were done with TTL chips on little
boards with bannana jacks, allowing convenient wiring during
the lecture.  Sometimes a logic block would be constructed during
one lecture, and in the next it would be replaced by a single PC
board doing the same function.  I believe that even now, seeing
TTL logic blocks connected together is a good way to begin to
learn logic design.  

For the lab classes, we built circuits with TTL and solderless
breadboards, but that was 30 years ago.  Even so, I don't believe
that one FPGA board for a whole lab class is right.  Each lab
station (which may be a few students) should have its own board
for that group to play with.  Those don't need to be owned by
the student.

The board that I was suggesting could also work there, but the
suggestion was for a board that the student would own.  To build
a project and take it home.  The price has to be low enough for
a student to afford, but the board has to be good enough for some
real projects.

-- glen
 

Article: 142439
Subject: Re: Spartan-6 Boards - Your Wish List
From: Dave Pollum <vze24h5m@verizon.net>
Date: Tue, 11 Aug 2009 11:22:57 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 11, 1:47=A0pm, Andy Peters <goo...@latke.net> wrote:
> On Aug 9, 5:44=A0am, John Adair <g...@enterpoint.co.uk> wrote:
>
> > Guys and Girls
>
> > Your chance to have input to what we bring to market as Spartan-6
> > products.
>
> > We have several release candidates nearly ready now but we can still
> > add or modify features and I am interested in features you would all
> > like to have in these boards either based on things we hve done before
> > in our product range or even new features you would like to see.
>
> > So go ahead and let us know what you want.
>
> I am sure a lot of audio types would like a daughter card with
> reasonable I2S-connected ADC and DAC devices.
>
> -a

Not to rain on John's parade, but Digilent, Inc. sells inexpensive
FPGA boards, plus (I believe) ADC and DAC add on modules.  I don't
know if they use the latest Xilinx chips or not.  I've been happy with
the Spartan-3 & 3E boards that I've bought from them.
-Dave Pollum

Article: 142440
Subject: Re: algorithm implementation in IC
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 11 Aug 2009 18:32:13 +0000 (UTC)
Links: << >>  << T >>  << A >>
jogging <joggingsong@gmail.com> wrote:

<   I'm not a FPGA engineer or IC designer.
< In fact, I'm a DSP engineer. So I have little
< knowledge about FPGA and IC design. I am
< wandering the way that a algorithm is implemented
< in IC. In IC desgin, the first step is algorithm
< design and C model implementation. Do algorithm
< engineers need to know FPGA implementation details
< In this step? 

I don't believe that they necessarily need FPGA implementation
details, but they do need to think in terms of logic design.

Some people believe that FPGA implementations are software
because they can be done in high-level languages like verilog,
or even C.  I disagree.  You have to be able to think in terms
of digital logic.  If you can do that, for example as TTL gates,
then I believe that you can do algorithm design for FPGAs.
It IS significantly different from DSP (software) design.

Once the algorithm has been designed, such as in the form 
of a systolic array, then someone else can do the actual
coding and optimizing for the specific FPGA.

-- glen

Article: 142441
Subject: Re: Spartan-6 Boards - Your Wish List
From: nico@puntnl.niks (Nico Coesel)
Date: Tue, 11 Aug 2009 19:19:19 GMT
Links: << >>  << T >>  << A >>
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

>Herbert Kleebauer <klee@unibwm.de> wrote:
>< glen herrmannsfeldt wrote:
> 
><> I am not sure what you would need to do to get a school to
><> start using a board, but I believe it would be better than
><> learning only through simulation.
> 
>< We use the DARNAW1 board in a beginners course (implementation
>< of a 16 bit minimal processor in a total time of about 12 hours).
>< But you don't need a board for every student but only one for
>< the class (downloading the bit file is just the final test).
>
>The frosh classes that I had consisted of a one term lecture class
>followed by a one term lab.  That was 30 years ago, so things might
>have changed over time.  Even so, the lecture class followed 
>(in the subsequent term) by a lab seems to work well.

30 years ago... All that is replaced with a course in Java programming
by now. IIRC we had to do a very boring I/O board for an ancient VME
system and program a driver for it in 68000 assembly but that is
already 12 years ago.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
                     "If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------

Article: 142442
Subject: Re: algorithm implementation in IC
From: Muzaffer Kal <kal@dspia.com>
Date: Tue, 11 Aug 2009 12:26:18 -0700
Links: << >>  << T >>  << A >>
On Tue, 11 Aug 2009 06:24:40 -0700 (PDT), Kolja
<ksulimma@googlemail.com> wrote:

>On 11 Aug., 11:01, jogging <joggings...@gmail.com> wrote:
>>  In IC desgin, the first step is algorithm
>> design and C model implementation.
>I always wondered why anyone would want to model the algorithms in
>C nowadays. There are so many nice modern languages around with
>object orientation, etc.
>Prototyping should be much quicker and less error prone with any of
>these compared to C.

Maybe it's because there are a lot of behavioral synthesis products
for C which actually work (or at least much more promising these days
(albeit very expensive)).
--
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

Article: 142443
Subject: Re: algorithm implementation in IC
From: Muzaffer Kal <kal@dspia.com>
Date: Tue, 11 Aug 2009 12:37:21 -0700
Links: << >>  << T >>  << A >>
On Tue, 11 Aug 2009 02:01:39 -0700 (PDT), jogging
<joggingsong@gmail.com> wrote:

>Hi,all
>   I'm not a FPGA engineer or IC designer.
>In fact, I'm a DSP engineer. So I have little
>knowledge about FPGA and IC design. I am
>wandering the way that a algorithm is implemented
>in IC. In IC desgin, the first step is algorithm
>design and C model implementation. Do algorithm
>engineers need to know FPGA implementation details
>In this step? If they have no idea about FPGA
>implementation, the algorithm may not be implemented
>efficiently in FPGA. When algorithm engineers know FPGA
>well they choose the efficent methods which can
>minimize area and power consumption. If FPGA engineers
>know little about algorithms, they can't make trade off
>between algorithm complexity and implementation efficiency.
>There is a gap between algorithm design and FPGA implementation.
>In IC industry, how is this problem solved?

While converting an algorithm implemented in C (with an underlying OS)
there are 3 main issues: 1) partitioning (which parts of the
implementation goes lower to hardware implementation and which parts
stay at processor level) 2) Scheduling 3) dynamic range (or floating
point vs fixed point).
Assuming partitioning is done early & correctly, the main issues of
ASIC/FPGA implementation are scheduling and dynamic range both of
which relate to hardware resource use. Scheduling requires decisions
on how much logic is needed in "one cycle" and is an optimization for
latency, hardware resource use and timing. Dynamic range is mostly for
hardware resource and timing (FP is big & slow).
So when doing algorithm development you need to pay attention to how
complicated the logic is in one cycle of a loop(s) and whether you are
using floating point numbers or whether you can implement all your
logic with integers. There are several tools which convert C to
Verilog RTL these days and you can see the results relatively quickly
to make changes to original C design. But nothing beats experience of
someone who codes in C and finally ports to Verilog to be able to tell
how easy the conversion will be.
--
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

Article: 142444
Subject: Re: algorithm implementation in IC
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 11 Aug 2009 19:43:29 +0000 (UTC)
Links: << >>  << T >>  << A >>
Muzaffer Kal <kal@dspia.com> wrote:
 
< Maybe it's because there are a lot of behavioral synthesis products
< for C which actually work (or at least much more promising these days
< (albeit very expensive)).

What do you mean by 'work'?

If there is software that can convert a serial dynamic programming
implementation into a systolic array in an FPGA I will be really really
surprised.

To me, the advantage to using C would be the ability to
use existing code, but serial code ports very poorly to hardware.
In addition, it allows people to believe that they can do logic
design without thinking about logic.  

Actually, I don't even code (for the most part) behavioral verilog.
(FFs can only be done in behavioral form, but I put them in a 
separate module, anyway.)

-- glen





Article: 142445
Subject: Re: algorithm implementation in IC
From: Muzaffer Kal <kal@dspia.com>
Date: Tue, 11 Aug 2009 13:06:43 -0700
Links: << >>  << T >>  << A >>
On Tue, 11 Aug 2009 19:43:29 +0000 (UTC), glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:

>Muzaffer Kal <kal@dspia.com> wrote:
> 
>< Maybe it's because there are a lot of behavioral synthesis products
>< for C which actually work (or at least much more promising these days
>< (albeit very expensive)).
>
>What do you mean by 'work'?
>
Check out the following products and decide for yourself:
Mentor Catapult C
Celoxica Handel C
Forte CSynthesizer
Synfora PICO

>If there is software that can convert a serial dynamic programming
>implementation into a systolic array in an FPGA I will be really really
>surprised.
>
Get ready to be surprised (to some degree).

>To me, the advantage to using C would be the ability to
>use existing code, but serial code ports very poorly to hardware.
>In addition, it allows people to believe that they can do logic
>design without thinking about logic.  

Nothing wrong with that as long as it increases productivity and
generates acceptable products. People had the same complaints about C
vs assembly, schematics vs Verilog/VHDL and even probably grunts vs
speech.
--
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

Article: 142446
Subject: Re: Spartan-6 Boards - Your Wish List
From: John Adair <g1@enterpoint.co.uk>
Date: Tue, 11 Aug 2009 14:18:43 -0700 (PDT)
Links: << >>  << T >>  << A >>
I'm not sure yet wether we will go down to the 40 pin with Craignell3.
We already have both Craignell1 and Craignell2 serving this size.
Craignell2 is a very good design. We put a lot of knowledge gained
from Craignell1 and we can go a 512Mbit SDRAM as an option for memory
and already have a 128Mbit Flash on there. All the Craignell3 would
bring is a little bigger memory and maybe some more logic. It would be
viable but we would need to find some market reason. However I won't
rule it out as a possibility. We have some interesting concept ideas
that we have as yet not talked about for the Craignell families. One
of those ideas is a possible good reason to do a 40 pin Craignell3 and
maybe even smaller pinouts.

Doing an oversize cut down we actually done that with the existing
parts for selected customer requirements so in practise it can be
done.

John Adair
Enterpoint Ltd.

On 11 Aug, 18:12, Marko Zec <z...@fer.hr> wrote:
> John Adair <g...@enterpoint.co.uk> wrote:
>
> ...
>
> > There other easy to use parts coming as well. The Craignell2 family
> > may expand with a larger pincount version assuming we don't have
> > Spartan-6 based Craignell3 there before it. Craignell3 will fill the
> > gaps better the Darnaw products and existing Craignell products.
>
> +1 vote here for Spartan-6 based Craignell3 with a large DDR2 / DDR3
> in say 80 pin version but still pluggable into 40 DIL sockets for
> legacy applications...
>
> Marko


Article: 142447
Subject: Re: Spartan-6 Boards - Your Wish List
From: John Adair <g1@enterpoint.co.uk>
Date: Tue, 11 Aug 2009 14:20:36 -0700 (PDT)
Links: << >>  << T >>  << A >>
I'll have a look at what our current stuff does cover in this area
but's low cost to add to a board and that could be done without budget
breaking.

John Adair
Enterpoint Ltd.

On 11 Aug, 18:47, Andy Peters <goo...@latke.net> wrote:
> On Aug 9, 5:44=A0am, John Adair <g...@enterpoint.co.uk> wrote:
>
> > Guys and Girls
>
> > Your chance to have input to what we bring to market as Spartan-6
> > products.
>
> > We have several release candidates nearly ready now but we can still
> > add or modify features and I am interested in features you would all
> > like to have in these boards either based on things we hve done before
> > in our product range or even new features you would like to see.
>
> > So go ahead and let us know what you want.
>
> I am sure a lot of audio types would like a daughter card with
> reasonable I2S-connected ADC and DAC devices.
>
> -a


Article: 142448
Subject: Re: Spartan-6 Boards - Your Wish List
From: John Adair <g1@enterpoint.co.uk>
Date: Tue, 11 Aug 2009 14:38:22 -0700 (PDT)
Links: << >>  << T >>  << A >>
And indeed many people buy their boards. They are reasonable products
but if you want to go further to a real product I don't think they are
interested in that. That's one of the big differences with us as a
commercial company and commercial targets and aims. Spartan-3 products
will remain suitable targets for many people for some time to come and
I expect we probably still be building Spartan-3 boards still in 5 to
10 years time even if we are doing Spartan-10 by then too.

I could talk also about their designs and make comments how we are
better and a pile of other things like that but that's not the point
of this post. I'm also not into negative posting as such and anyway
they are just one of many compeditors I need to not worry about. This
also should only be a postive post to get feedback on how Enterpoint
makes better products for the market. Our products already do the
talking for us in many cases but I'm not complacent that we can't
improve or do it better. Not every development board will suit every
customer but there is a trick to providing a solution that's useful in
some way.

John Adair
Enterpoint Ltd.

On 11 Aug, 19:22, Dave Pollum <vze24...@verizon.net> wrote:
> On Aug 11, 1:47=A0pm, Andy Peters <goo...@latke.net> wrote:
>
>
>
> > On Aug 9, 5:44=A0am, John Adair <g...@enterpoint.co.uk> wrote:
>
> > > Guys and Girls
>
> > > Your chance to have input to what we bring to market as Spartan-6
> > > products.
>
> > > We have several release candidates nearly ready now but we can still
> > > add or modify features and I am interested in features you would all
> > > like to have in these boards either based on things we hve done befor=
e
> > > in our product range or even new features you would like to see.
>
> > > So go ahead and let us know what you want.
>
> > I am sure a lot of audio types would like a daughter card with
> > reasonable I2S-connected ADC and DAC devices.
>
> > -a
>
> Not to rain on John's parade, but Digilent, Inc. sells inexpensive
> FPGA boards, plus (I believe) ADC and DAC add on modules. =A0I don't
> know if they use the latest Xilinx chips or not. =A0I've been happy with
> the Spartan-3 & 3E boards that I've bought from them.
> -Dave Pollum


Article: 142449
Subject: Is it possible to use OSERDES and ISERDES primitives internal to
From: Test01 <cpandya@yahoo.com>
Date: Tue, 11 Aug 2009 15:02:57 -0700 (PDT)
Links: << >>  << T >>  << A >>
 I have a design1 that uses OSERDES and ISERDES prmitives to serialize
and de-seriliaze the data at the I/O.  This design1 seems to be
working fine but we need to use it test some other design - design2.
So we would like to connect the design1 to design2 inside the virtex4
FPGA and test it in the real hardware.  There is some justification to
do this so for now please go along with it.

As it is OSERDES and ISERDES primitives are for the I/O pins to
communicate to the outside world at higher speed.  But in my
application i need to use that serial interface in the Virtex4 fabric
itself to test the design2.

I am under the impression that using ISERDES and OSERDES in this
manner is not possible.  Is that correct?  I can create my own
serializer and de-serilizer that can work in the fabric but I am not
sure if there is a better way to do this.

Thanks.

CP



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