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 149050

Article: 149050
Subject: Re: Xilinx XST and a State Machine - A Mystery
From: "jmiles@pop.net" <jmiles@gmail.com>
Date: Mon, 27 Sep 2010 00:05:19 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 20, 9:05=A0am, John McCaskill <jhmccask...@gmail.com> wrote:
> On Sep 20, 10:52=A0am, Darol Klawetter <darol.klawet...@l-3com.com>
> wrote:
>
> > I recently fixed a problem with one of my state machines, and I think
> > that the cause could be a bug in Xilinx XST. Below is the code that
> > produced the failure. The state-machine worked most of the time,
> > though occasionally the 'phaseRamWE' signal would be stuck low, even
> > though I could see 'phaseRamReadAdr' and 'phaseRamWriteAdr'
> > incrementing. =A0I fixed it by explicitly declaring the desired value o=
f
> > 'phaseRamWE' in every state. Notice that all states are defined so it
> > should recover from any conditions introduced by asynchronous inputs.
>
> > Have any of you seen similar behavior? Appears to be an XST bug to me.
>
> <snip>
>
> I only skimmed the code, but this bit jumped out at me:
>
> =A0 =A0 =A0 =A0 =A0 =A0 if (pipeFill =3D=3D 1'b1) =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 // 'pipeFill' is
> asynchronous to 'clk'
>
> If pipeFill is really asynchronous to the clock that is running your
> state machine, =A0using it without synchronizing it first is going to
> cause you problems. =A0Probably not because of metastability, but
> because of coherency problems. If pipeFill is changing near the clock
> edge, some FFs will see the new value, and some the old. =A0This can
> cause weird and flaky behaviour.

So, could he have fixed the problem by not writing to both state and
phaseRamWE in S1?  E.g.,

 S1:
    begin
       if (pipeFill =3D=3D 1'b1)
       begin
          // phaseRamWE <=3D 1'b1;
          state <=3D S1A; // was S2
       end
    end


S1A:
     begin
         phaseRamWE <=3D 1'b1;
         state <=3D S2;
     end

S2:
   ...

My understanding is that this would still be hazardous because there's
no guarantee that all of the bits composing the 'state' value are
guaranteed to toggle.  Even though there's only one "variable" that
changes in response to pipeFill, the same failure mode still exists as
long as the register itself is more than one bit wide.

Being relatively new to Verilog, it seems that the textbooks warn
extensively about metastability (which as noted below isn't as big a
problem as it used to be) but not much about coherency at all.  I can
see how Darol became complacent, since it's easy to see the S1->S2
transition as an all-or-nothing event...

-- john, KE5FX

Article: 149051
Subject: Re: Virtex6 quote
From: Royston Teo <roystonzhang@gmail.com>
Date: Mon, 27 Sep 2010 02:01:04 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 24, 9:45=A0am, Muzaffer Kal <k...@dspia.com> wrote:
> On Thu, 23 Sep 2010 12:32:22 -0700 (PDT), fasf
>
> <silusilus...@gmail.com> wrote:
> >On 23 Set, 18:19, Uwe Bonnes <b...@elektron.ikp.physik.tu-
> >darmstadt.de> wrote:
> >> fasf <silusilus...@gmail.com> wrote:
> >> > Hi,
> >> > i received a quote for a Virtex6 XC6VLX75T of 200USD for unit: is it
> >> > possible or is it an error?
> >> > Thanks
>
> >> findchips.com let one assume it's an error or fake...
>
> >I dind't know that site: but seems it not work very well....for
> >example, if i find XC6VLX75T, from digikey i have no results....
>
> At digikey the least expensive (not in stock) xc6vlx75 is $764 for one
> unit. Avnet has very small numbers of these chips and the price seems
> to be around $600 for one unit. The price you're given is not a
> reasonable number. Obviously it's not from Avnet which is the only
> authorized distributor for Xilinx at this point.
> --
> Muzaffer Kal
>
> DSPIA INC.
> ASIC/FPGA Design Services
>
> http://www.dspia.com

If we are to buy more than 200 pieces and find Avnet price is high,
who can we approach?
If we approach the distributor directly, they will ask us the program
name, end user name.

Article: 149052
Subject: Spartan 3 DCM problem
From: "mokhoo" <amn257@n_o_s_p_a_m.yahoo.com>
Date: Mon, 27 Sep 2010 05:53:16 -0500
Links: << >>  << T >>  << A >>
Dear All,
I am working on project using Xilinx Spartan3 XC3S2000. I have used one DCM
and it worked well. However, when I tried to instantiate another one for
other purpose, errors appeared in the building phase as follows:

ERROR:NgdBuild:604 - logical block 'CLK_1/DCM_inst' with type 'DCM_2'
could
   not be resolved. A pin name misspelling can cause this, a missing edif
or ngc
   file, or the misspelling of a type name. Symbol 'DCM_2' is not supported
in
   target 'spartan3'.

ERROR:NgdBuild:604 - logical block 'CLK_2/DCM_IFCLK' with type 'DCM_1'
   could not be resolved. A pin name misspelling can cause this, a missing
edif
   or ngc file, or the misspelling of a type name. Symbol 'DCM_1' is not
   supported in target 'spartan3'.
 
Concerning the above problem I have two questions:
1. Why adding another DCM fails?
2. Why adding another DCM affects the first one although they are not
related to each other in the design?

Thanks and best regards,


	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 149053
Subject: FPGA For Image Processing[Economical]
From: "mitho" <adnan.siddiq@n_o_s_p_a_m.live.com>
Date: Mon, 27 Sep 2010 05:53:26 -0500
Links: << >>  << T >>  << A >>
Hi.
We are working on a image processing based on FPGA. But we are confused
about which FPGA to select. We looked for ML 410 virtex-4. But its too
costly around $3000. Can anybody suggest a relative cheap and efficient
FPGA. Thanks

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 149054
Subject: question when using asmi_parallel ip core
From: "PaulHam" <hamsdeji@n_o_s_p_a_m.gmail.com>
Date: Mon, 27 Sep 2010 05:53:38 -0500
Links: << >>  << T >>  << A >>
Hi,all

I'm Paul Ham in Korea and have some difficulties in using ASMI_PARALLEL
altera ip core.
Anyone who knows well this problem could advice to me.

I'm using Cyclone FPGA with EPCS4 and Quartus V9.1 without service pack.
My design is very simple like below :
1) receive the data from PC via RS232.
   The data is .rpd file made by Conver Programming Files of Quartus menu.
   Due to the EPCS spec, its size is 512KByte.
2) write the data to internal dpram. (double buffering)
3) read the data from dpram to asmi_parallel every 256 bytes.(page write)

When I simulated it with signaltap, it wrote other .rpd file into EPCS4
well.
And it configured well after power-up.

But it didn't work when I programmed itself directly to EPCS4.
It always generate the illegal_erase and illegal_write.

I found some ways to solve the problem like below but anything didn't work
well.
1) make 4 pins related to configuration, nCS/ASDO/DCLK/DATA0, "USE AS
REGULAR IO" at .qsf file.
   -> set_global_assignment -name RESERVE_ASDO_AFTER_CONFIGURATION "USE AS
REGULAR IO"
      set_global_assignment -name RESERVE_DATA0_AFTER_CONFIGURATION "USE AS
REGULAR IO"
      set_global_assignment -name RESERVE_DCLK_AFTER_CONFIGURATION "USE AS
REGULAR IO"
      set_global_assignment -name RESERVE_FLASH_NCE_AFTER_CONFIGURATION
"USE AS REGULAR IO"
2) modify the value of "ncs_reg" in asmi_parallel.v as below.
   -> always @ ( negedge clkin_wire or  posedge end_ophdly)
	 if (end_ophdly == 1'b1) ncs_reg <= 1'b1; 
	 else if  (wire_ncs_reg_ena == 1'b1)   ncs_reg <= 1'b0;
3) install the service pack 1 : I didn't try it

I guess that the problem is related to the setting of 4 configuration
pins.
But I'm not sure what could I do.
If you have any advice or solution, please let me know.

Thanks advance
Regards
Paul


	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 149055
Subject: Re: FPGA For Image Processing[Economical]
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 27 Sep 2010 11:09:12 +0000 (UTC)
Links: << >>  << T >>  << A >>
mitho <adnan.siddiq@n_o_s_p_a_m.live.com> wrote:

> We are working on a image processing based on FPGA. But we are confused
> about which FPGA to select. We looked for ML 410 virtex-4. But its too
> costly around $3000. Can anybody suggest a relative cheap and efficient
> FPGA. Thanks

It is hard to say without knowing more about your algorithms
and the size of the problems, but in many cases the Spartan
series provides more gates/$.  

-- glen

Article: 149056
Subject: Re: Spartan 3 DCM problem
From: Gabor <gabor@alacron.com>
Date: Mon, 27 Sep 2010 07:06:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 27, 6:53=A0am, "mokhoo" <amn257@n_o_s_p_a_m.yahoo.com> wrote:
> Dear All,
> I am working on project using Xilinx Spartan3 XC3S2000. I have used one D=
CM
> and it worked well. However, when I tried to instantiate another one for
> other purpose, errors appeared in the building phase as follows:
>
> ERROR:NgdBuild:604 - logical block 'CLK_1/DCM_inst' with type 'DCM_2'
> could
> =A0 =A0not be resolved. A pin name misspelling can cause this, a missing =
edif
> or ngc
> =A0 =A0file, or the misspelling of a type name. Symbol 'DCM_2' is not sup=
ported
> in
> =A0 =A0target 'spartan3'.
>
> ERROR:NgdBuild:604 - logical block 'CLK_2/DCM_IFCLK' with type 'DCM_1'
> =A0 =A0could not be resolved. A pin name misspelling can cause this, a mi=
ssing
> edif
> =A0 =A0or ngc file, or the misspelling of a type name. Symbol 'DCM_1' is =
not
> =A0 =A0supported in target 'spartan3'.
>
> Concerning the above problem I have two questions:
> 1. Why adding another DCM fails?
> 2. Why adding another DCM affects the first one although they are not
> related to each other in the design?
>
> Thanks and best regards,
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com

I have seen issues like this in some versions of ISE, but only for
mixed
VHDL / Verilog designs.  What I found was that if I instantiated a
primitive
module in both Verilog and VHDL modules within the design, then ISE
would append a number to the primitive name, and then it couldn't find
the
.ngc file because it didn't have the same name as the library
primitive
after appending the number.  I believe this has been fixed in more
recent versions of ISE.  I think I was working with ISE 8.x at the
time.

My workaround at the time was to synthesize only the VHDL portion of
the
design with one project, turning off IO buffers.  Then the Verilog
part
of the design (which in my case was the top level) instantiated the
pre-built VHDL design as a black box using the .ngc file created
from the VHDL project.

In my case the offending primitives were block RAM's and I had another
workaround that used Coregen to make RAM's instead of using the
RAMB_xx primitives.

Regards,
Gabor

Article: 149057
Subject: Re: Xilinx XST and a State Machine - A Mystery
From: Darol Klawetter <darol.klawetter@l-3com.com>
Date: Mon, 27 Sep 2010 07:28:02 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 27, 2:05=A0am, "jmi...@pop.net" <jmi...@gmail.com> wrote:
> On Sep 20, 9:05=A0am, John McCaskill <jhmccask...@gmail.com> wrote:
>
>
>
> > On Sep 20, 10:52=A0am, Darol Klawetter <darol.klawet...@l-3com.com>
> > wrote:
>
> > > I recently fixed a problem with one of my state machines, and I think
> > > that the cause could be a bug in Xilinx XST. Below is the code that
> > > produced the failure. The state-machine worked most of the time,
> > > though occasionally the 'phaseRamWE' signal would be stuck low, even
> > > though I could see 'phaseRamReadAdr' and 'phaseRamWriteAdr'
> > > incrementing. =A0I fixed it by explicitly declaring the desired value=
 of
> > > 'phaseRamWE' in every state. Notice that all states are defined so it
> > > should recover from any conditions introduced by asynchronous inputs.
>
> > > Have any of you seen similar behavior? Appears to be an XST bug to me=
.
>
> > <snip>
>
> > I only skimmed the code, but this bit jumped out at me:
>
> > =A0 =A0 =A0 =A0 =A0 =A0 if (pipeFill =3D=3D 1'b1) =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 // 'pipeFill' is
> > asynchronous to 'clk'
>
> > If pipeFill is really asynchronous to the clock that is running your
> > state machine, =A0using it without synchronizing it first is going to
> > cause you problems. =A0Probably not because of metastability, but
> > because of coherency problems. If pipeFill is changing near the clock
> > edge, some FFs will see the new value, and some the old. =A0This can
> > cause weird and flaky behaviour.
>
> So, could he have fixed the problem by not writing to both state and
> phaseRamWE in S1? =A0E.g.,
>
> =A0S1:
> =A0 =A0 begin
> =A0 =A0 =A0 =A0if (pipeFill =3D=3D 1'b1)
> =A0 =A0 =A0 =A0begin
> =A0 =A0 =A0 =A0 =A0 // phaseRamWE <=3D 1'b1;
> =A0 =A0 =A0 =A0 =A0 state <=3D S1A; // was S2
> =A0 =A0 =A0 =A0end
> =A0 =A0 end
>
> S1A:
> =A0 =A0 =A0begin
> =A0 =A0 =A0 =A0 =A0phaseRamWE <=3D 1'b1;
> =A0 =A0 =A0 =A0 =A0state <=3D S2;
> =A0 =A0 =A0end
>
> S2:
> =A0 =A0...
>
> My understanding is that this would still be hazardous because there's
> no guarantee that all of the bits composing the 'state' value are
> guaranteed to toggle. =A0Even though there's only one "variable" that
> changes in response to pipeFill, the same failure mode still exists as
> long as the register itself is more than one bit wide.
>
> Being relatively new to Verilog, it seems that the textbooks warn
> extensively about metastability (which as noted below isn't as big a
> problem as it used to be) but not much about coherency at all. =A0I can
> see how Darol became complacent, since it's easy to see the S1->S2
> transition as an all-or-nothing event...
>
> -- john, KE5FX

John,

The same failure mode would exist, as you suspected. As has been said
before, there are state machines that can tolerate asynchronous inputs
(I thought that my first version of this machine could do so, since I
thought that all states were defined and all states would provide a
path for recovery), but it's simpler, less error-prone, and tool-
independent to just synchronize all inputs.

Article: 149058
Subject: Re: Virtex5 minimodule
From: Royston Teo <roystonzhang@gmail.com>
Date: Mon, 27 Sep 2010 08:33:54 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 25, 2:05=A0am, John Adair <g...@enterpoint.co.uk> wrote:
> I'm not sure you will find anything like this as a standard item but
> we could offer it as a custom.
>
> John Adair
> Enterpoint Ltd.
>
> On 24 Sep, 12:26, eryer <idkfaidkfaid...@gmail.com> wrote:
>
>
>
> > Hi,
> > I'm looking for a Virtex5 XC5VLX50T-1FFG1136C devboard with small
> > dimension, low cost and these features
> > 1. LVDS output (15channels)
> > 2. Ethernet port
> > 3. USB port
> > or 2USB ports....any help?- Hide quoted text -
>
> - Show quoted text -

Hey John Adair,
Then i wonder if you are able to provide the Xilinx Device with good
pricings, i mean really good pricings.
I can purchase them in lot. My email roystonzhang@gmail.com

Article: 149059
Subject: Re: Xilinx XST and a State Machine - A Mystery
From: Andy <jonesandy@comcast.net>
Date: Mon, 27 Sep 2010 08:51:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 27, 9:28=A0am, Darol Klawetter <darol.klawet...@l-3com.com>
wrote:
> On Sep 27, 2:05=A0am, "jmi...@pop.net" <jmi...@gmail.com> wrote:
>
>
>
>
>
> > On Sep 20, 9:05=A0am, John McCaskill <jhmccask...@gmail.com> wrote:
>
> > > On Sep 20, 10:52=A0am, Darol Klawetter <darol.klawet...@l-3com.com>
> > > wrote:
>
> > > > I recently fixed a problem with one of my state machines, and I thi=
nk
> > > > that the cause could be a bug in Xilinx XST. Below is the code that
> > > > produced the failure. The state-machine worked most of the time,
> > > > though occasionally the 'phaseRamWE' signal would be stuck low, eve=
n
> > > > though I could see 'phaseRamReadAdr' and 'phaseRamWriteAdr'
> > > > incrementing. =A0I fixed it by explicitly declaring the desired val=
ue of
> > > > 'phaseRamWE' in every state. Notice that all states are defined so =
it
> > > > should recover from any conditions introduced by asynchronous input=
s.
>
> > > > Have any of you seen similar behavior? Appears to be an XST bug to =
me.
>
> > > <snip>
>
> > > I only skimmed the code, but this bit jumped out at me:
>
> > > =A0 =A0 =A0 =A0 =A0 =A0 if (pipeFill =3D=3D 1'b1) =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 // 'pipeFill' is
> > > asynchronous to 'clk'
>
> > > If pipeFill is really asynchronous to the clock that is running your
> > > state machine, =A0using it without synchronizing it first is going to
> > > cause you problems. =A0Probably not because of metastability, but
> > > because of coherency problems. If pipeFill is changing near the clock
> > > edge, some FFs will see the new value, and some the old. =A0This can
> > > cause weird and flaky behaviour.
>
> > So, could he have fixed the problem by not writing to both state and
> > phaseRamWE in S1? =A0E.g.,
>
> > =A0S1:
> > =A0 =A0 begin
> > =A0 =A0 =A0 =A0if (pipeFill =3D=3D 1'b1)
> > =A0 =A0 =A0 =A0begin
> > =A0 =A0 =A0 =A0 =A0 // phaseRamWE <=3D 1'b1;
> > =A0 =A0 =A0 =A0 =A0 state <=3D S1A; // was S2
> > =A0 =A0 =A0 =A0end
> > =A0 =A0 end
>
> > S1A:
> > =A0 =A0 =A0begin
> > =A0 =A0 =A0 =A0 =A0phaseRamWE <=3D 1'b1;
> > =A0 =A0 =A0 =A0 =A0state <=3D S2;
> > =A0 =A0 =A0end
>
> > S2:
> > =A0 =A0...
>
> > My understanding is that this would still be hazardous because there's
> > no guarantee that all of the bits composing the 'state' value are
> > guaranteed to toggle. =A0Even though there's only one "variable" that
> > changes in response to pipeFill, the same failure mode still exists as
> > long as the register itself is more than one bit wide.
>
> > Being relatively new to Verilog, it seems that the textbooks warn
> > extensively about metastability (which as noted below isn't as big a
> > problem as it used to be) but not much about coherency at all. =A0I can
> > see how Darol became complacent, since it's easy to see the S1->S2
> > transition as an all-or-nothing event...
>
> > -- john, KE5FX
>
> John,
>
> The same failure mode would exist, as you suspected. As has been said
> before, there are state machines that can tolerate asynchronous inputs
> (I thought that my first version of this machine could do so, since I
> thought that all states were defined and all states would provide a
> path for recovery), but it's simpler, less error-prone, and tool-
> independent to just synchronize all inputs.- Hide quoted text -
>
> - Show quoted text -

Not disregarding all the caveats already mentioned, but a better way
to do this would be to set phaseRamWE in S1, and then transition from
S1 to S2 based on phaseRamWE, which is synchronous (though
metastable), instead of pipeFill.

Andy

Article: 149060
Subject: Re: FPGA For Image Processing[Economical]
From: Tim Wescott <tim@seemywebsite.com>
Date: Mon, 27 Sep 2010 09:15:53 -0700
Links: << >>  << T >>  << A >>
On 09/27/2010 03:53 AM, mitho wrote:
> Hi.
> We are working on a image processing based on FPGA. But we are confused
> about which FPGA to select. We looked for ML 410 virtex-4. But its too
> costly around $3000. Can anybody suggest a relative cheap and efficient
> FPGA. Thanks

Sure, but it may not even begin to work.  "Image processing" covers just 
about anything from diddling with the pixel contrast on a still image up 
through feeding the video from a football game into one end and getting 
intelligent commentary out the other.  The first can be done with an 
8051 processor with expanded memory, the second often can't even be done 
with a highly paid sportscaster in the loop.

You need to estimate what sort of gate count and speeds you need to 
accomplish your desired task.  Only then can you even hope to determine 
what FPGA (or processor, or combination thereof) would most economically 
meet your goals.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

Article: 149061
Subject: Re: FPGA For Image Processing[Economical]
From: nico@puntnl.niks (Nico Coesel)
Date: Mon, 27 Sep 2010 18:38:34 GMT
Links: << >>  << T >>  << A >>
"mitho" <adnan.siddiq@n_o_s_p_a_m.live.com> wrote:

>Hi.
>We are working on a image processing based on FPGA. But we are confused
>about which FPGA to select. We looked for ML 410 virtex-4. But its too
>costly around $3000. Can anybody suggest a relative cheap and efficient
>FPGA. Thanks

It takes a lot of Spartans to make the price of a Virtex. But like the
others pointed out: what do you want to do? Ever thought of running
your algorithm on a PC?

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

Article: 149062
Subject: Re: FPGA For Image Processing[Economical]
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Mon, 27 Sep 2010 18:59:17 +0000 (UTC)
Links: << >>  << T >>  << A >>
Nico Coesel <nico@puntnl.niks> wrote:
> "mitho" <adnan.siddiq@n_o_s_p_a_m.live.com> wrote:

> >Hi.
> >We are working on a image processing based on FPGA. But we are confused
> >about which FPGA to select. We looked for ML 410 virtex-4. But its too
> >costly around $3000. Can anybody suggest a relative cheap and efficient
> >FPGA. Thanks

> It takes a lot of Spartans to make the price of a Virtex. But like the
> others pointed out: what do you want to do? Ever thought of running
> your algorithm on a PC?

It take a lot of logic to keep all DSP Units of a XC3SD1800 or a XC6SLX45
running...  
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 149063
Subject: Re: Stack Exchange site for programmable logic and FPGA design
From: steve ravet <steve.ravet@gmail.com>
Date: Mon, 27 Sep 2010 13:42:37 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 19, 12:17=A0pm, saar drimer <saardri...@gmail.com> wrote:
> Hello comp.arch.fpga,
>
> tl;dr first: I created a proposal for a Stack Exchange site for
> "programmable logic and FPGA design"; if you'd like to support it,
> (register and then) "follow" it:
>
> =A0http://area51.stackexchange.com/proposals/20632/programmable-logic-an.=
..
>
> I'm a long time comp.arch.fpga lurker (about 10 years) with a grand
> track record of very few actual posts. Over the years, and recently,
> alternatives to this place on usenet were discussed. I think it is
> fair to say that the "community" can do better than what usenet
> currently has to offer compared to community-support sites for other
> topics. I've spent quite a few cycles thinking and researching what's
> the best way to get a vendor-independent community-based-and-moderated
> support site that will bring us to modern times.
>
> The best I could come up with will give us what I think we need --
> *but*, it will take some patience and a bit of effort.
>
> "Stack Exchange" (SE;http://stackexchange.com/) is a set of sites
> that allow users to ask technical questions and receive answers from
> experts, whose only rewards is ranking, not money. The idea in the
> open source community is that once you achieve a certain status
> (rank), you'd convert it into contracting gigs or a better job;
> basically, you become more visible to the people who may want to hire
> you. I think this can work for the people on comp.arch.fpga quite
> well. Here's one of the sites, Stack Overflow:
>
> =A0http://stackoverflow.com/
>
> SE creators have authored a framework that is hard to imitate (there
> are OSS clones out there), and they've now chosen an unorthodox usage-
> model for it. It's called "area 51":
>
> =A0http://area51.stackexchange.com/
>
> Basically, people propose themes for an SE sites, then in the
> "definition" phase people have to "follow" it and define what are good
> and bad topics; then in the "commitment" stage people commit to
> contribute; then there's a public beta, and then it becomes an
> official site that is "forever" hosted by SE. Their FAQ is here:
>
> =A0http://area51.stackexchange.com/faq
>
> I created a proposal for "programmable logic and FPGA design" SE site
> here:
>
> =A0http://area51.stackexchange.com/proposals/20632/programmable-logic-an.=
..
>
> I want people's feedback, and support if they think this is a good
> idea -- just register if you need to, "follow" and suggest questions
> if you feel like it. If you have reputation on the SE network your
> commitment will eventually count for more (a slight problem of the
> scheme, imo). In presentation, the site appears as "question and
> answers" place, though there is no reason not to use it for discussion
> as well -- I hope that once the site reaches the final stage it could
> be customized a little bit.
>
> Just to be absolutely clear, I have no affiliation with SE, and
> frankly I don't care much for their usage model, though as community-
> based-and-moderated support sites go, I think they have a pretty good
> thing going.
>
> cheers,
> saar.
>
> http://www.saardrimer.com

I think it's a good idea, I just signed up.

--steve

Article: 149064
Subject: Adding PLB Module to AMBA
From: Paul Ranger <Paul_nospam@hotmail.com>
Date: Mon, 27 Sep 2010 23:13:42 +0100
Links: << >>  << T >>  << A >>
Hi all,

Hope this here is the right newsgroup: I have a SoC with an AMBA bus but 
now I have to add a module that has an PLB interface. So I am wondering 
if anyone did this in the past and can tell me what is the best 
approach. Is there maybe something like a "tutorial" where I am
told which PLB signals map to which AMBA signals?

Many thanks,
Paul

Article: 149065
Subject: Re: FPGA For Image Processing[Economical]
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Mon, 27 Sep 2010 18:55:31 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 27, 3:53=A0am, "mitho" <adnan.siddiq@n_o_s_p_a_m.live.com> wrote:
> Hi.
> We are working on a image processing based on FPGA. But we are confused
> about which FPGA to select. We looked for ML 410 virtex-4. But its too
> costly around $3000. Can anybody suggest a relative cheap and efficient
> FPGA. Thanks
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com

There may be some confusion here.  Your post mentioned that you were
trying to select a cost effective FPGA for you work, which implies
that you are planning on building a custom system, but then you made a
reference to the cost of a Virtex-4 ML410 development system.

Are you concerned about the cost of a development system for
research?  Or the component cost for a custom system?

Ed McGettigan
--
Xilinx Inc.

Article: 149066
Subject: Re: Xilinx XST and a State Machine - A Mystery
From: KJ <kkjennings@sbcglobal.net>
Date: Mon, 27 Sep 2010 21:15:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 27, 11:51=A0am, Andy <jonesa...@comcast.net> wrote:
>
> Not disregarding all the caveats already mentioned, but a better way
> to do this would be to set phaseRamWE in S1, and then transition from
> S1 to S2 based on phaseRamWE, which is synchronous (though
> metastable), instead of pipeFill.
>

I'm assuming that you're comparing what you outlined to that of
explicit synchronizers as had been pointed out...so by what measure
could you possibly consider what you listed as a 'better way'?
Different perhaps, but better?  Some ways I see it to be worse are:

- Encourages use (and down the road misuse) of asynchronous signals in
a state machine.  If the misuse creeps back in, the same flaky
behavior pops back up (hopefully while still in the lab, and not after
having been deployed).
- State machine must be re-written to add a state (or two) if one
changes their mind and wants to have the additional insurance of a
second (or third) synchronizer.
- While only an aesthetics thing, synchronizing signals to a clock has
nothing to do with the state machine logic and does not 'belong'
there.  Synchronized inputs are simply a prerequisite for the inputs
to the state machine.

How do you see what you wrote being 'better'?

KJ

Article: 149067
Subject: Re: FPGA For Image Processing[Economical]
From: John Adair <g1@enterpoint.co.uk>
Date: Tue, 28 Sep 2010 00:19:14 -0700 (PDT)
Links: << >>  << T >>  << A >>
For lower cost you want to thing about Spartan-3 and Spartan-6. From
the Spartan-3 side the XC3SD3400A is a good part ideally because is is
richer in memory and DSP elements. From the board level backing this
up with DDR memory is a good idea as we have done on our Hollybush2
development board http://www.enterpoint.co.uk/oem_industrial/hollybush2.htm=
l.

Spartan-6 potentially offers a even better solution with an increase
in logic size, memory and DSP elements. Again backing up with DDR
memory is probably a good idea and we have this in all of the 3
Spartan-6 products we are now shipping. In particular look at our PCIe
solution Raggedstone2 http://www.enterpoint.co.uk/raggedstone/raggedstone2.=
html
and our compact Drigmorn4 http://www.enterpoint.co.uk/drigmorn/drigmorn4.ht=
ml.
As the Spartan-6 supply situation has improved vastly in the last few
weeks we now have the capability to build these boards in hundreds off
rather than 10 off and that will show in our stock levels in the next
few weeks. We also have some new chip size variants of these coming as
well.

John adair
Enterpoint Ltd.

On 27 Sep, 11:53, "mitho" <adnan.siddiq@n_o_s_p_a_m.live.com> wrote:
> Hi.
> We are working on a image processing based on FPGA. But we are confused
> about which FPGA to select. We looked for ML 410 virtex-4. But its too
> costly around $3000. Can anybody suggest a relative cheap and efficient
> FPGA. Thanks
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com


Article: 149068
Subject: Re: FPGA For Image Processing[Economical]
From: dgreig <dgreig@ieee.org>
Date: Tue, 28 Sep 2010 00:59:51 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 28, 8:19=A0am, John Adair <g...@enterpoint.co.uk> wrote:
> For lower cost you want to thing about Spartan-3 and Spartan-6. From
> the Spartan-3 side the XC3SD3400A is a good part ideally because is is
> richer in memory and DSP elements. From the board level backing this
> up with DDR memory is a good idea as we have done on our Hollybush2
> development boardhttp://www.enterpoint.co.uk/oem_industrial/hollybush2.ht=
ml.
>
> Spartan-6 potentially offers a even better solution with an increase
> in logic size, memory and DSP elements. Again backing up with DDR
> memory is probably a good idea and we have this in all of the 3
> Spartan-6 products we are now shipping. In particular look at our PCIe
> solution Raggedstone2http://www.enterpoint.co.uk/raggedstone/raggedstone2=
.html
> and our compact Drigmorn4http://www.enterpoint.co.uk/drigmorn/drigmorn4.h=
tml.
> As the Spartan-6 supply situation has improved vastly in the last few
> weeks we now have the capability to build these boards in hundreds off
> rather than 10 off and that will show in our stock levels in the next
> few weeks. We also have some new chip size variants of these coming as
> well.
>
> John adair
> Enterpoint Ltd.
>
> On 27 Sep, 11:53, "mitho" <adnan.siddiq@n_o_s_p_a_m.live.com> wrote:
>
> > Hi.
> > We are working on a image processing based on FPGA. But we are confused
> > about which FPGA to select. We looked for ML 410 virtex-4. But its too
> > costly around $3000. Can anybody suggest a relative cheap and efficient
> > FPGA. Thanks
>
> > --------------------------------------- =A0 =A0 =A0 =A0
> > Posted throughhttp://www.FPGARelated.com

Multipliers/$ and memory/$ and ability to run multicycle and
available:
Lattice ECP3 or Altera Cyclone, with the ECP3 being very desirous with
a Synplify Pro vendor toolflow.

Article: 149069
Subject: Re: Virtex5 minimodule
From: Bryan <bryan.fletcher@avnet.com>
Date: Tue, 28 Sep 2010 06:11:57 -0700 (PDT)
Links: << >>  << T >>  << A >>
Not exactly what you asked for, but similar.  This comes in a 30T or
70T and the FF665 package.
  www.em.avnet.com/virtex5mini

Bryan

On Sep 24, 7:26=A0am, eryer <idkfaidkfaid...@gmail.com> wrote:
> Hi,
> I'm looking for a Virtex5 XC5VLX50T-1FFG1136C devboard with small
> dimension, low cost and these features
> 1. LVDS output (15channels)
> 2. Ethernet port
> 3. USB port
> or 2USB ports....any help?


Article: 149070
Subject: Re: FPGA For Image Processing[Economical]
From: John Adair <g1@enterpoint.co.uk>
Date: Tue, 28 Sep 2010 06:41:48 -0700 (PDT)
Links: << >>  << T >>  << A >>
Don't worry we are not forgetting alternative technologies. I will be
talking about something a bit different in our range before too long.

John Adair
Enterpoint Ltd.

On 28 Sep, 08:59, dgreig <dgr...@ieee.org> wrote:
> On Sep 28, 8:19=A0am, John Adair <g...@enterpoint.co.uk> wrote:
>
>
>
> > For lower cost you want to thing about Spartan-3 and Spartan-6. From
> > the Spartan-3 side the XC3SD3400A is a good part ideally because is is
> > richer in memory and DSP elements. From the board level backing this
> > up with DDR memory is a good idea as we have done on our Hollybush2
> > development boardhttp://www.enterpoint.co.uk/oem_industrial/hollybush2.=
html.
>
> > Spartan-6 potentially offers a even better solution with an increase
> > in logic size, memory and DSP elements. Again backing up with DDR
> > memory is probably a good idea and we have this in all of the 3
> > Spartan-6 products we are now shipping. In particular look at our PCIe
> > solution Raggedstone2http://www.enterpoint.co.uk/raggedstone/raggedston=
e2.html
> > and our compact Drigmorn4http://www.enterpoint.co.uk/drigmorn/drigmorn4=
.html.
> > As the Spartan-6 supply situation has improved vastly in the last few
> > weeks we now have the capability to build these boards in hundreds off
> > rather than 10 off and that will show in our stock levels in the next
> > few weeks. We also have some new chip size variants of these coming as
> > well.
>
> > John adair
> > Enterpoint Ltd.
>
> > On 27 Sep, 11:53, "mitho" <adnan.siddiq@n_o_s_p_a_m.live.com> wrote:
>
> > > Hi.
> > > We are working on a image processing based on FPGA. But we are confus=
ed
> > > about which FPGA to select. We looked for ML 410 virtex-4. But its to=
o
> > > costly around $3000. Can anybody suggest a relative cheap and efficie=
nt
> > > FPGA. Thanks
>
> > > --------------------------------------- =A0 =A0 =A0 =A0
> > > Posted throughhttp://www.FPGARelated.com
>
> Multipliers/$ and memory/$ and ability to run multicycle and
> available:
> Lattice ECP3 or Altera Cyclone, with the ECP3 being very desirous with
> a Synplify Pro vendor toolflow.


Article: 149071
Subject: Re: Xilinx XST and a State Machine - A Mystery
From: Andy <jonesandy@comcast.net>
Date: Tue, 28 Sep 2010 09:00:45 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 27, 11:15=A0pm, KJ <kkjenni...@sbcglobal.net> wrote:
>
> I'm assuming that you're comparing what you outlined to that of
> explicit synchronizers as had been pointed out...>
snip...
> How do you see what you wrote being 'better'?
>
> KJ

No, I was trying to say it was better than jmiles' suggestion. I think
I replied to the wrong message...

Explicit synchronization is just as effective, and in many ways
superior to the method I suggested (especially WRT reviewing the
design).

One functional advantage of the method I suggested (I'll call it
embedded synchronization), compared to explicit synchronization, is
that multiple asynchronous inputs can be synchronized with one
synchronous flag register, so long as not more than one of those
asynchronous inputs can change simultaneously (which can cause
glitches in LUT based combinatorial logic).

Another functional advantage of embedded synchronization is that, if
you are re-using a synchronous output you already needed in the first
place (as was the case in my example), and that output needs to be
qualified with the state, then this method reduces the latency from
asynchronous input to synchronized, qualified output. Note that if
adequate timing slack is not available to allow potential
metastability to expire, then you will need an additional
synchronization stage (and additional latency). The qualification
could be combined in the meta-rejection stage by embedding that stage
only, while leaving the initial synchronization stage external to the
state machine.

Additional states are not required for additional stages of
synchronization. Simply add those register assignments to the existing
state (like a shift register), and only transition to the next state
when the last one is set.

Opinions vary on what "belongs" in a state machine. When operations
are simple, including them in a state machine is often easier to
follow than creating the status and control logic necessary to
interface with operations outside the state machine. In this case,
these are simple enough that there would be no extra status/control
specified, but you get the idea (e.g. embedding count logic in the
state machine, etc.) IMHO, if adding the logic in the state is simpler
and easier, then I do it. If it is long and tedious, and detracts from
the "flow" of the state machine, I don't. For instance, do you always
strip nested if statements out of state machines, and externally
generate the flags that will be used as "simple inputs" to the state
machine? I'm not saying either method is wrong or right for you or
anyone else, but I am saying which methods are preferable for me.

Andy

Article: 149072
Subject: Re: Adding PLB Module to AMBA
From: steve ravet <steve.ravet@gmail.com>
Date: Tue, 28 Sep 2010 10:17:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi Paul, I hadn't heard of PLB before, I assume it's the powerPC
Processor Local Bus?

Also, AMBA is a suite of protocols, you need to specify which AMBA bus
you are working with:  APB, AHB, AXI

In any case, they are different protocols so the signals don't map,
you'll need a bridge to connect the two.

--steve

On Sep 27, 5:13=A0pm, Paul Ranger <Paul_nos...@hotmail.com> wrote:
> Hi all,
>
> Hope this here is the right newsgroup: I have a SoC with an AMBA bus but
> now I have to add a module that has an PLB interface. So I am wondering
> if anyone did this in the past and can tell me what is the best
> approach. Is there maybe something like a "tutorial" where I am
> told which PLB signals map to which AMBA signals?
>
> Many thanks,
> Paul


Article: 149073
Subject: Re: Adding PLB Module to AMBA
From: Paul Ranger <Paul_nospam@hotmail.com>
Date: Tue, 28 Sep 2010 18:47:43 +0100
Links: << >>  << T >>  << A >>
Hi Steve,

> I hadn't heard of PLB before, I assume it's the powerPC
> Processor Local Bus?

Yes, exactly. This is the one I am talking about.

> Also, AMBA is a suite of protocols, you need to specify which AMBA bus
> you are working with:  APB, AHB, AXI

Preferably, I connect it to the AHB bus, but for a start also the APB
bus would be an option just to get it working.

> In any case, they are different protocols so the signals don't map,
> you'll need a bridge to connect the two.

Yes, I am aware that I have to adapt this implementation somehow. I have
an okay understanding of the AMBA bus, but did not check in detail the 
PLB. Is there maybe such a bridging interface available anywhere? Or
does someone know a module with wrappers for AHB and PLB, maybe I could
use then a similar approach.

Thanks,
Paul

Article: 149074
Subject: Re: Virtex5 minimodule
From: Kolja Sulimma <ksulimma@googlemail.com>
Date: Wed, 29 Sep 2010 01:15:35 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 24 Sep., 13:26, eryer <idkfaidkfaid...@gmail.com> wrote:
> Hi,
> I'm looking for a Virtex5 XC5VLX50T-1FFG1136C devboard with small
> dimension, low cost and these features
> 1. LVDS output (15channels)
> 2. Ethernet port
> 3. USB port
> or 2USB ports....any help?

It depends on what you consider small:
http://shop.trenz-electronic.de/catalog/product_info.php?products_id=734

Kolja



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