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 153850

Article: 153850
Subject: Re: PRNG
From: rickman <gnuarm@gmail.com>
Date: Tue, 5 Jun 2012 12:13:39 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 1, 2:36=A0pm, Thomas Heller <thel...@ctypes.org> wrote:
> Am 01.06.2012 18:57, schrieb Tim Wescott:
>
>
>
>
>
>
>
>
>
> > On Fri, 01 Jun 2012 17:02:10 +0100, Thomas Womack wrote:
>
> >> In article<a2s3v7Fv1...@mid.individual.net>, Thomas Heller
> >> <thel...@ctypes.org> =A0wrote:
> >>> I need a multi-bit PRNG which generates a sequence of 10-bit pseudo
> >>> random numbers.
>
> >>> Can I use a LFSR of sufficient length (31 bit, for example), and get =
a
> >>> new random number on each clock by using the 10 least significant bit=
s,
> >>> or do I have to use 10 independent LFSR's of different length, one fo=
r
> >>> each bit?
>
> >> How important is it that the numbers are uncorrelated? =A0The 10 LSBs =
of
> >> an LFSR at time t+1 will be nine of the bits from time t and one new
> >> one, so if you saw 100 at time t you know it's either 200 or 201 next
> >> go. =A0If that's OK, use the end of one LFSR; if not, use several.
>
> >> But if it's actually important that the random numbers are
> >> unpredictable, don't use LFSRs: given 3n bits from a length-n LFSR you
> >> can pretty much write down the rest of the sequence.
>
> > I've only scratched the surface of cryptographicaly secure random numbe=
r
> > generation -- are there any schemes that are amenable to working on an
> > FPGA?
>
> FYI: =A0I found interesting papers about true (and pseudo) random number
> generation in FPGAs. =A0They are using ff metastability or PLL jitter
> for this:
>
> http://people.csail.mit.edu/devadas/pubs/ches-fpga-random.pdf
>
> http://www.cse.cuhk.edu.hk/~phwl/mt/public/archives/papers/tprng_fccm...
>
> Thomas

I haven't read the papers, but typically any digital "true" random
number generator is not "truly" random.  When it is measured and
analyzed critically it has biases which allow a degree of
predictability.  I have read about other attempts based on diode noise
which resulted in easily measurable biases.

Rick

Article: 153851
Subject: Re: PRNG
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 5 Jun 2012 20:17:05 +0000 (UTC)
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:

(snip, someone wrote)
>> >>> Can I use a LFSR of sufficient length (31 bit, for example), and get a
>> >>> new random number on each clock by using the 10 least significant bits,
>> >>> or do I have to use 10 independent LFSR's of different length, one for
>> >>> each bit?

>> FYI:  I found interesting papers about true (and pseudo) random number
>> generation in FPGAs.  They are using ff metastability or PLL jitter
>> for this:

>> http://people.csail.mit.edu/devadas/pubs/ches-fpga-random.pdf

>> http://www.cse.cuhk.edu.hk/~phwl/mt/public/archives/papers/tprng_fccm...

> I haven't read the papers, but typically any digital "true" random
> number generator is not "truly" random.  When it is measured and
> analyzed critically it has biases which allow a degree of
> predictability.  

If you put enough state bits into the calculation, you should be
able to keep the predictability long enough that, in a practical
time frame, it isn't noticed. 

> I have read about other attempts based on diode noise
> which resulted in easily measurable biases.

I used to have the paper about an Intel chip with a built-in
noise source based generator. There is logic to remove at least
the first order bias. (Equal ones and zeros.) It should be possible
to remove any specific bias if you know about it and try to
remove it. You need to know which biases the specific problem
is sensitive to.

I do remember stories about many of the early generators that
weren't so bad except when taken in triplets there was some
correlation between triplets. That turned out bad when used to
generate points in 3D space. Once known, it can be fixed.

There is always a tradeoff between randomness and time needed
by the generator.

-- glen

Article: 153852
Subject: MPMC does not finish initialization in simulation
From: "shubhendu" <toshubhendu@n_o_s_p_a_m.yahoo.com>
Date: Wed, 06 Jun 2012 09:43:11 -0500
Links: << >>  << T >>  << A >>
Hello Friends, 

I am working on virtex6. I am trying to debug a problem by simulating in
modelsim. But in the simulation I get a different problem. My platform uses
DDR3 SDRAM via xilinx's MPMC (6.02a). 

During simulation, the MPMC gets busy initializing itself, but never
finishes (at least not for until 2ms). 

To fasten the initialization in the MHS file, I first set 
PARAMETER C_SKIP_SIM_INIT_DELAY = 1

That didnt help. So to be sure I also then set 

PARAMETER C_MEM_SIM_INIT_OPTION = SKIP_INIT
PARAMETER C_MEM_WRLVL = 0

I see WRITE level initialization finishes, but read level does not. The
simulation continues forever ( I simulated for 2ms, which took around 1Hr
with my hardware platform)

What could be wrong? Have I missed something?

I am not memory expert, I just want the MPMC to work during simulation. 


Thanks



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

Article: 153853
Subject: Re: MPMC does not finish initialization in simulation
From: Robert Miles <robertmilesxyz@gmail.com>
Date: Wed, 6 Jun 2012 23:33:11 -0700 (PDT)
Links: << >>  << T >>  << A >>
I can't help with that.

However, back when I was doing simulations, they usually finished sometime during the night after I started them.  However, I once saw a simulation (of a circuit board with mostly ASIC on it) that took three months to finish.

Article: 153854
Subject: TCE 1.6
From: Pekka Jaaskelainen <pekka.jaaskelainen@nosPAM.invalid>
Date: Thu, 7 Jun 2012 11:04:39 +0000 (UTC)
Links: << >>  << T >>  << A >>
TTA-based Co-design Environment (TCE) v1.6 released
---------------------------------------------------

TTA-based Co-design Environment (TCE) is a toolset for designing
application-specific processors based on the Transport Triggered
Architecture (TTA). The toolset provides a complete retargetable co-design
flow from high-level language programs down to synthesizable processor
RTL (VHDL and Verilog backends supported) and parallel program binaries.
Processor customization points include the register files, function units,
supported operations, and the interconnection network.

This release adds support for LLVM 3.1, experimental Verilog backend
for the Processor Generator, support for explicit access to multiple
address spaces from C, a simplified C++ interface for accessing the
simulation engine, automated generation of clustered-style TTA
machines, experimental vector input and a bottom-up instruction
scheduler. See the CHANGES file for a more thorough change listing.

Acknowledgements
----------------
Many thanks to Kalle Raiskila who submitted his first code contributions
to this release. Keep them coming!

We'd like to thank the Radio Implementation Research Team from Nokia
Research Center which funded a significant part of the work for developing
this release. Much appreciated!

Links
-----

TCE home page:     http://tce.cs.tut.fi
This announcement: http://tce.cs.tut.fi/downloads/ANNOUNCEMENT
Download:          http://tce.cs.tut.fi/downloads
Change log:        http://tce.cs.tut.fi/downloads/CHANGES 


Article: 153855
Subject: FPGA Interconnect
From: "bukka" <bukka4@n_o_s_p_a_m.hotmail.com>
Date: Thu, 07 Jun 2012 09:56:59 -0500
Links: << >>  << T >>  << A >>
Hi,

Here is a question little bit in the internals of the FPGA. I am asking
this more out of my curiosity and learning.

FPGA LUT typically consists of SRAMs & a Mux at the output. These Muxes
need both normal & inverted select signals. The select signals come from
the interconnect. Considering the inverted select signals, there are two
possible implementations –

Implementation-1
CLB-1 [To] Switch Mux [To] Switch Buffer [To] Interconnect Line to Carry
TRUE Signal [To] CLB-N

In such a case there have to be inverters within the LUT Mux to get
inverted signals.

Implementation-2
CLB-1 [To] Switch Mux [To] Switch Buffer [To] Interconnect Line to Carry
Normal Signal & Interconnect Line to carry Inverted Signal [To] CLB-N

Implementation-2 will be inefficient in terms of area & power. However
Implementation-1 will have additional one inverter delay in the critical
path.

Does anybody has an idea which one is favored in the FPGAs.
Please get back.

Thanks,
Bukka


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

Article: 153856
Subject: Re: PRNG
From: rickman <gnuarm@gmail.com>
Date: Thu, 7 Jun 2012 09:48:48 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 5, 4:17=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> rickman <gnu...@gmail.com> wrote:
>
> (snip, someone wrote)
>
> >> >>> Can I use a LFSR of sufficient length (31 bit, for example), and g=
et a
> >> >>> new random number on each clock by using the 10 least significant =
bits,
> >> >>> or do I have to use 10 independent LFSR's of different length, one=
 for
> >> >>> each bit?
> >> FYI: I found interesting papers about true (and pseudo) random number
> >> generation in FPGAs. They are using ff metastability or PLL jitter
> >> for this:
> >>http://people.csail.mit.edu/devadas/pubs/ches-fpga-random.pdf
> >>http://www.cse.cuhk.edu.hk/~phwl/mt/public/archives/papers/tprng_fccm..=
.
> > I haven't read the papers, but typically any digital "true" random
> > number generator is not "truly" random. =A0When it is measured and
> > analyzed critically it has biases which allow a degree of
> > predictability.
>
> If you put enough state bits into the calculation, you should be
> able to keep the predictability long enough that, in a practical
> time frame, it isn't noticed.
>
> > I have read about other attempts based on diode noise
> > which resulted in easily measurable biases.
>
> I used to have the paper about an Intel chip with a built-in
> noise source based generator. There is logic to remove at least
> the first order bias. (Equal ones and zeros.) It should be possible
> to remove any specific bias if you know about it and try to
> remove it. You need to know which biases the specific problem
> is sensitive to.
>
> I do remember stories about many of the early generators that
> weren't so bad except when taken in triplets there was some
> correlation between triplets. That turned out bad when used to
> generate points in 3D space. Once known, it can be fixed.
>
> There is always a tradeoff between randomness and time needed
> by the generator.
>
> -- glen

Yes, it all depends on what you need.

I was watching a local government cable channel once about a state
hearing where a representative of a gambling machine company was
trying to explain to the regulating board how this machine was
different from the machines prohibited in this state.  It seems that
there were machines that for some amount of coin would give you a pre-
printed ticket that told you your winnings, if any.  Because the
sequence was pre-arranged and once the prizes have all sold out (the
barkeeper would know when that happens) the remaining tickets were all
losers and further play was no longer "gambling".  So the gaming board
banned these machines.

This spokesperson claimed that the microprocessors in the machine
always produced random results and so was not like the illegal pre-
printed ticket machines.  We all know that this is nonsense and that
they actually were using something like an LFSR, possibly with a time
based modification that would not produce truly random results.  For
example, I expect their machines would never produce a sequence of 100
big winners no matter how long you played.  A real random machine
would produce this sequence eventually if played long enough.

I don't know what the outcome of the hearing was.  I suspect the
gaming commission got more info from other sources and learned that a
microprocessor does not produce random results.

Rick

Article: 153857
Subject: Re: EDK problems
From: hdlnerd@gmail.com
Date: Thu, 7 Jun 2012 11:57:52 -0700 (PDT)
Links: << >>  << T >>  << A >>
My experience with Altera embedded is limited to taking a short Altera-pres=
ented class on their new tools and (of course) it all worked beautifully, w=
ith some really nice bells and whistles for debugging and putting together =
a quick TCL-base GUI.  Since this is in a controlled environment, take it f=
or what it's worth...

I can, however, second your frustration with the Xilinx EDK.  Every time I =
make a change to a peripheral on our design, getting the flow to work again=
 is always very painful.  The tool is very unreliable in how it converts ac=
tions in the GUI (XPS) to actual instructions for the platform generator (.=
MHS file) and it's often that I/O changes don't show up in the file, and th=
at resulting processor no longer works with the debugger, even when you *th=
ink* you've correctly regenerated the "base system package" (*_bsp project =
in XSDK) and done everything right.

I also burned up 2-3 days when I was new to the environment because the Lin=
ux version of XSDK has some GUI quirks that make it unclear which .ELF file=
 you're loading when you attempt to debug the device with the JTAG cable.  =
The default file in the pull-down list may show your current compiled progr=
am, but it actually loads it with bootloop.elf (do-nothing code) unless you=
 explicitly pull-down the list and "re-select" it.

We're going to be starting an Altera project within a month or two and I ea=
gerly anticipate what kind of "gotchas" we encounter in their tools.  I hop=
e to be pleasantly surprised.
--
Kevin Smith
HDL Nerd for Hire

On Monday, May 28, 2012 3:20:40 PM UTC-5, maxascent wrote:
> Does anyone have experience of using the Altera and Xilinx embedded
> software? I have been using EDK but I am getting very frustrated with it.
> It seems that every new release includes a generous helping of bugs. I se=
em
> to find myself wasting hours just trying to get a design to be implemente=
d.
> For example the 14.1 release now seems to have some problems with the
> interrupt controller, yet it was ok in the previous release. Does the
> Altera software have as many bugs?
>=20
> TIA
>=20
> Jon
>=20
> 	  =20
> 				=09
> ---------------------------------------	=09
> Posted through http://www.FPGARelated.com


Article: 153858
Subject: Re: FPGA Interconnect
From: hdlnerd@gmail.com
Date: Thu, 7 Jun 2012 12:54:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
At the risk of misunderstanding your question, I think that your "Implement=
ation-1" would not really have an additional inverter delay if it's going t=
o be input to a function that will fit into a single LUT (up to 4 inputs - =
6 if you count the neighboring LUT in the same slice).  The propagation del=
ay through:

Y =3D A + B

is exactly the same as the delay through:

Y =3D (!(A * B) +  C) * (!D + A)

because either is implemented as a 16-bit ROM with a 4-bit address input an=
d a 1-bit data output.

So sending your inverted signal along with the normal signal would waste a =
routing resource and the automatic tools would be unlikely to do it that wa=
y.

Best wishes,
--
Kevin Smith
HDL Nerd for Hire


On Thursday, June 7, 2012 9:56:59 AM UTC-5, bukka wrote:
> Hi,
>=20
> Here is a question little bit in the internals of the FPGA. I am asking
> this more out of my curiosity and learning.
>=20
> FPGA LUT typically consists of SRAMs & a Mux at the output. These Muxes
> need both normal & inverted select signals. The select signals come from
> the interconnect. Considering the inverted select signals, there are two
> possible implementations =96
>=20
> Implementation-1
> CLB-1 [To] Switch Mux [To] Switch Buffer [To] Interconnect Line to Carry
> TRUE Signal [To] CLB-N
>=20
> In such a case there have to be inverters within the LUT Mux to get
> inverted signals.
>=20
> Implementation-2
> CLB-1 [To] Switch Mux [To] Switch Buffer [To] Interconnect Line to Carry
> Normal Signal & Interconnect Line to carry Inverted Signal [To] CLB-N
>=20
> Implementation-2 will be inefficient in terms of area & power. However
> Implementation-1 will have additional one inverter delay in the critical
> path.
>=20
> Does anybody has an idea which one is favored in the FPGAs.
> Please get back.
>=20
> Thanks,
> Bukka
>=20
>=20
> 	  =20
> 				=09
> ---------------------------------------	=09
> Posted through http://www.FPGARelated.com


Article: 153859
Subject: Re: FPGA Interconnect
From: goouse99@googlemail.com
Date: Thu, 7 Jun 2012 22:48:45 -0700 (PDT)
Links: << >>  << T >>  << A >>
Am Donnerstag, 7. Juni 2012 16:56:59 UTC+2 schrieb bukka:
> Hi,
>=20
> Here is a question little bit in the internals of the FPGA. I am asking
> this more out of my curiosity and learning.
>=20
> FPGA LUT typically consists of SRAMs & a Mux at the output. These Muxes
> need both normal & inverted select signals. The select signals come from
> the interconnect. Considering the inverted select signals, there are two
> possible implementations =96
>=20
> Implementation-1
> CLB-1 [To] Switch Mux [To] Switch Buffer [To] Interconnect Line to Carry
> TRUE Signal [To] CLB-N
>=20
> In such a case there have to be inverters within the LUT Mux to get
> inverted signals.
>=20
> Implementation-2
> CLB-1 [To] Switch Mux [To] Switch Buffer [To] Interconnect Line to Carry
> Normal Signal & Interconnect Line to carry Inverted Signal [To] CLB-N
>=20
> Implementation-2 will be inefficient in terms of area & power. However
> Implementation-1 will have additional one inverter delay in the critical
> path.
>=20
> Does anybody has an idea which one is favored in the FPGAs.
> Please get back.
>=20
> Thanks,
> Bukka
>=20
>=20
> 	  =20
> 				=09
> ---------------------------------------	=09
> Posted through http://www.FPGARelated.com

Hi Bukka,
I think it doesn't make much sense to think about the internals of a LUT in=
 terms of gates and wires.
These blocks are highly optimized monolithic units made out of transistors.
If any selection signals (which are the LUTS inputs) need inversion interna=
lly, this functionality will be absorbed and timing optimized within the tr=
ansistor layout the LUT is made of.

Have a nice synthesis
  Eilert

Article: 153860
Subject: Re: FPGA Interconnect
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 8 Jun 2012 06:17:56 +0000 (UTC)
Links: << >>  << T >>  << A >>
goouse99@googlemail.com wrote:

(snip)

> I think it doesn't make much sense to think about the 
> internals of a LUT in terms of gates and wires.
> These blocks are highly optimized monolithic units made 
> out of transistors.  If any selection signals (which are 
> the LUTS inputs) need inversion internally, this 
> functionality will be absorbed and timing optimized 
> within the transistor layout the LUT is made of.

That is true, but many engineers like to know how things
work inside. In this case, your best hope is probably patents.

As it isn't so hard to open up an IC and figure out how it
works, the best protection is a patent. Maybe not all the
details you want, but some might be there.

-- glen


Article: 153861
Subject: Re: MPMC does not finish initialization in simulation
From: Gabor <gabor@szakacs.invalid>
Date: Fri, 08 Jun 2012 10:22:07 -0400
Links: << >>  << T >>  << A >>
shubhendu wrote:
> Hello Friends, 
> 
> I am working on virtex6. I am trying to debug a problem by simulating in
> modelsim. But in the simulation I get a different problem. My platform uses
> DDR3 SDRAM via xilinx's MPMC (6.02a). 
> 
> During simulation, the MPMC gets busy initializing itself, but never
> finishes (at least not for until 2ms). 
> 
> To fasten the initialization in the MHS file, I first set 
> PARAMETER C_SKIP_SIM_INIT_DELAY = 1
> 
> That didnt help. So to be sure I also then set 
> 
> PARAMETER C_MEM_SIM_INIT_OPTION = SKIP_INIT
> PARAMETER C_MEM_WRLVL = 0
> 
> I see WRITE level initialization finishes, but read level does not. The
> simulation continues forever ( I simulated for 2ms, which took around 1Hr
> with my hardware platform)
> 
> What could be wrong? Have I missed something?
> 
> I am not memory expert, I just want the MPMC to work during simulation. 
> 
> 
> Thanks
> 
> 
> 
> 	   
> 					
> ---------------------------------------		
> Posted through http://www.FPGARelated.com

I'm not familiar with the MPMC, but I had issues with MIG simulations
not finishing "calibration."  It seems that my problem had to do with
a minimum delay requirement on the data path.  If you look at the
test bench provided with the MIG design, there are delays in the
data connections between MIG and the memory model.  You may need to
duplicate these in your test bench if they're not already in there.

-- Gabor

Article: 153862
Subject: Reading out LUTM content
From: Reinhard <reinhard.haemmerle@yahoo.com>
Date: Sun, 10 Jun 2012 20:40:39 +0100
Links: << >>  << T >>  << A >>
Hi all,

Following problem: We have an Xilinx Virtix 5, having an implementation 
running on it. What we want to do, is to read out all the bits (or the 
state) of the different LUTM cells.

At the moment, we are outputting this information with the help of an 
UART module. However, we are wondering whether we could completely get
rid of the UART and use the JTAG instead somehow.

So without using Chipscop, is there a way that allows us to readback all
LUTM contents using the JTAG interface?

Many thanks!

Article: 153863
Subject: Virtex 4 Cameralink DCM Limitation
From: "ees3dc" <d.cooke@n_o_s_p_a_m.sstl.co.uk>
Date: Thu, 14 Jun 2012 06:11:04 -0500
Links: << >>  << T >>  << A >>
I have a cameralink (LVDS SERDES) I'm trying to capture data with using a
Virtex 4 mature product. I have ported the XAPP485 deserializer using V4
primitives (slightly different to Spartan3A) and configured the DCM to run
at 32MHz. 

The problem is the LVDS-TTL receivers on the PCB cannot run at the 32MHz x7
rate. The slow risetime means I hardly see a 2V '1' threshold in the
Xilinx.

I therefore need to reduce the incoming clock rate, but the DCM minimum
frequency is 32MHz.... 

OK, I could reduce the cameralink down to 20MHz giving 1/20e6*7 bit period
of 7.14ns. I have a 200MHz clock on the board for IDELAY, I could use both
edges to oversample the cameralink data (and 20MHz subclock to ease data
recovery) by sampling at 2.5ns. But this is going to be a nightmare to
peice together (it can be done offline) and require lots of storage......

Is there a more elegant way of capturing the data please?

The application is to take an image of a satellite on seperation from the
launcher in space - its a nice to have but I'd really like to make this
work.

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

Article: 153864
Subject: FPGA FIFO MAX data speed
From: "markc" <yuzhe_zhang@n_o_s_p_a_m.hotmail.com>
Date: Thu, 14 Jun 2012 06:11:07 -0500
Links: << >>  << T >>  << A >>
hi, guys:

i'm designing a fifo using XILINX FPGA V6. the fifo will be used to
transport data between ARM11(OR POWERPC) and TI DSP 6474. i know it's
related to the bus clock of both side, but how to calculate the max data
rate that can be transferred.
can anyone tell me how?
thanks!

markc

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

Article: 153865
Subject: Re: Virtex 4 Cameralink DCM Limitation
From: Gabor <gabor@szakacs.invalid>
Date: Thu, 14 Jun 2012 10:21:54 -0400
Links: << >>  << T >>  << A >>
ees3dc wrote:
> I have a cameralink (LVDS SERDES) I'm trying to capture data with using a
> Virtex 4 mature product. I have ported the XAPP485 deserializer using V4
> primitives (slightly different to Spartan3A) and configured the DCM to run
> at 32MHz. 
> 
> The problem is the LVDS-TTL receivers on the PCB cannot run at the 32MHz x7
> rate. The slow risetime means I hardly see a 2V '1' threshold in the
> Xilinx.
> 
> I therefore need to reduce the incoming clock rate, but the DCM minimum
> frequency is 32MHz.... 
> 
> OK, I could reduce the cameralink down to 20MHz giving 1/20e6*7 bit period
> of 7.14ns. I have a 200MHz clock on the board for IDELAY, I could use both
> edges to oversample the cameralink data (and 20MHz subclock to ease data
> recovery) by sampling at 2.5ns. But this is going to be a nightmare to
> peice together (it can be done offline) and require lots of storage......
> 
> Is there a more elegant way of capturing the data please?
> 
> The application is to take an image of a satellite on seperation from the
> launcher in space - its a nice to have but I'd really like to make this
> work.
> 
> 	   
> 					
> ---------------------------------------		
> Posted through http://www.FPGARelated.com

Well it's more rework to your board, but the real way to do this is to
bring the LVDS right into the V4 instead of using receivers.  I've never
used V4, but at least in V5 I found that I needed to use PLL's instead
of DCM's for a reliable 7:1 deserialization.  If you were going to
convert signals to TTL levels, then it would make a lot more sense
to use the National DS90CR288A chips instead of just receivers.
Sampling with an asynchronous clock sounds like a nightmare.

-- Gabor

Article: 153866
Subject: Re: Virtex 4 Cameralink DCM Limitation
From: carltonnbd@gmail.com
Date: Thu, 14 Jun 2012 13:01:22 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Thursday, June 14, 2012 7:11:04 AM UTC-4, ees3dc wrote:
> I have a cameralink (LVDS SERDES) I'm trying to capture data with using a
> Virtex 4 mature product. I have ported the XAPP485 deserializer using V4
> primitives (slightly different to Spartan3A) and configured the DCM to ru=
n
> at 32MHz.=20
>=20
> The problem is the LVDS-TTL receivers on the PCB cannot run at the 32MHz =
x7
> rate. The slow risetime means I hardly see a 2V '1' threshold in the
> Xilinx.
>=20
> I therefore need to reduce the incoming clock rate, but the DCM minimum
> frequency is 32MHz....=20
>=20
> OK, I could reduce the cameralink down to 20MHz giving 1/20e6*7 bit perio=
d
> of 7.14ns. I have a 200MHz clock on the board for IDELAY, I could use bot=
h
> edges to oversample the cameralink data (and 20MHz subclock to ease data
> recovery) by sampling at 2.5ns. But this is going to be a nightmare to
> peice together (it can be done offline) and require lots of storage......
>=20
> Is there a more elegant way of capturing the data please?
>=20
> The application is to take an image of a satellite on seperation from the
> launcher in space - its a nice to have but I'd really like to make this
> work.
>=20
> 	  =20
> 				=09
> ---------------------------------------	=09
> Posted through http://www.FPGARelated.com

ees3dc,

Some thoughts:

If you are at the frequency limit of your LVDS translation buffers, you wil=
l have no choice but to lower the clock frequency on the transmit input sid=
e such that
your LVDS translation buffers then work with a cameralink clock which is 7x=
 of the transmit as well as receive side clocks. That is true regardless of=
 whatever approach you take within the FPGA. If you must push it, and you d=
esire all the margin on the logic levels you can get,then because at the FP=
GA the IOB is a receiver, you could make the input buffer a LVCMOS25 which =
has a Vin of 1.7v instead of 2.0v.


Check out the datasheet, the 32MHz lower bound is for the clkoutx. For clkd=
v, it is 2MHz. Hence you should be able to derive a clock which is 1:7 from=
 the cameralink clock using the DCM. Higher input frequency can be an issue=
 as then the DCM jitter comes into play so be careful. I suspect it is one =
(of possibly many) reasons Xilinx had to introduce PLLs in their successors=
 to the Virtex-4 when bit rates got beyond the ~3-500Mbps range.


An issue you will have is that while this derived receive side clock is for=
 all intents and purposes of the same frequency of the transmit side clock,=
 there is no (easy) way to guarantee they are both in phase. As such, you w=
ill need to double-buffer the de-serializers for each of the 4 streams on t=
he cameralink so that nothing is missed. This of course then followed by sy=
nchronizing to the derived receive clock.

Regards,
Carlton

Article: 153867
Subject: Fpga to Asic conversion, firm list and prices.
From: Mario Volks <kwiateq0007@gmail.com>
Date: Fri, 15 Jun 2012 11:32:47 +0200
Links: << >>  << T >>  << A >>
Maybe is time write more about price and about firm specialized in 
PGA-to-ASIC replacement.

Please, add company name and Your experience with company. Some details 
about price for sample, some detail about low, med or high volume 
production.

Best Mario.

Article: 153868
Subject: Re: Fpga to Asic conversion, firm list and prices.
From: Jon <jon@beniston.com>
Date: Fri, 15 Jun 2012 03:07:48 -0700 (PDT)
Links: << >>  << T >>  << A >>
The price will vary massively depending on your design, the target technology, as well what non-logic blocks you've been using in the FPGA and any FPGA vendor supplied IP. 

You could be looking at a cost anywhere from $50k to several million $. 

Cheers,
Jon

Article: 153869
Subject: Re: FPGA FIFO MAX data speed
From: Mawa_fugo <ccon67@netscape.net>
Date: Fri, 15 Jun 2012 11:16:15 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 14, 6:11=A0am, "markc" <yuzhe_zhang@n_o_s_p_a_m.hotmail.com>
wrote:
> hi, guys:
>
> i'm designing a fifo using XILINX FPGA V6. the fifo will be used to
> transport data between ARM11(OR POWERPC) and TI DSP 6474. i know it's
> related to the bus clock of both side, but how to calculate the max data
> rate that can be transferred.
> can anyone tell me how?
> thanks!
>
> markc
>
> ---------------------------------------
> Posted throughhttp://www.FPGARelated.com

Usually the max speed is slower one

Let say, you can make $10,000 each month,..but your spouse can spend
max $6,666 per 30 days

so the max you can give her (via the FIFO mail box) is $6,666/month...
because if you give her more than that she will give $$$ to someone
else





Article: 153870
Subject: Re: Virtex 4 Cameralink DCM Limitation
From: Gabor <gabor@szakacs.invalid>
Date: Fri, 15 Jun 2012 18:16:29 -0400
Links: << >>  << T >>  << A >>
carltonnbd@gmail.com wrote:
[snip]

 > An issue you will have is that while this derived receive side clock
 > is for all intents and purposes of the same frequency of the transmit
 > side clock, there is no (easy) way to guarantee they are both in
 > phase. As such, you will need to double-buffer the de-serializers for
 > each of the 4 streams on the cameralink so that nothing is missed.
 > This of course then followed by synchronizing to the derived receive
 > clock.

I'm not sure I follow you on this one.  If you look at the transmit
diagram in the DS90CR287 data sheet, the clock signal looks like any
other data line with a word of 1100011, i.e. it is high for 4 bit
periods and low for three, and a data word starts in the middle of
a clock high period.  All of my Camera Link receiver designs treat
the clock like a 5th data line.  I deserialize it and use the 0->1
transition to predict a word starting two cycles later.  In a Virtex
5 I have to play some games to route the clk pair to a PLL as well
as the deserializer.  I'm not sure if V4 has any similar restrictions.

-- Gabor

Article: 153871
Subject: Re: FPGA FIFO MAX data speed
From: Mike Young <boat042-spam@yahoo.com>
Date: Fri, 15 Jun 2012 23:41:37 -0500
Links: << >>  << T >>  << A >>
On 06/14/2012 06:11 AM, markc wrote:
> hi, guys:
>
> i'm designing a fifo using XILINX FPGA V6. the fifo will be used to
> transport data between ARM11(OR POWERPC) and TI DSP 6474. i know it's
> related to the bus clock of both side, but how to calculate the max data
> rate that can be transferred.
> can anyone tell me how?
> thanks!
>
> markc

The various time values are tabulated in the switching characteristics 
section of the device data sheet. Their descriptions are in the device 
user guide. Both documents are available at the Xilinx website.


Article: 153872
Subject: Re: Virtex 4 Cameralink DCM Limitation
From: carltonnbd@gmail.com
Date: Mon, 18 Jun 2012 09:01:52 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi Gabor,

If I understand your approach correctly, you are using the higher clock rat=
e further into the chain. As such, your approach with detecting the rising =
edge makes perfect sense. There is no need for the second register set.

What I was referring to had the presumption that it is/was desired to trans=
ition to the slower clock. For example, perhaps right after the de-serializ=
er. Because the de-serializer is always working when the link is active and=
 because there is a phase shift relative to the slower clock, it is necessa=
ry to additionally register right after the de-serializer to permit alignme=
nt to the slower clock while at the same time not dropping or losing anythi=
ng.

Also note, that my comment about the DCM was backwards. I meant to mention =
a 1:7 not 7:1. For some reason I got on a 7:1 track. Woops. To pull off a 1=
:7  will require 2 DCMs. The first operates in a mode to permit a lower (th=
an 32MHz) CLKIN frequency but outputs (a) a CLKFX higher frequency clock co=
mpatible with the second DCM and (b) a regenerated slower clock. The second=
 DCM receives the now compatible clock from the first DCM and creates the f=
inal overall 1:7.

Regards,
Carlton

Article: 153873
Subject: Re: Virtex 4 Cameralink DCM Limitation
From: Gabor <gabor@szakacs.invalid>
Date: Mon, 18 Jun 2012 15:31:46 -0400
Links: << >>  << T >>  << A >>
carltonnbd@gmail.com wrote:
> Hi Gabor,
> 
> If I understand your approach correctly, you are using the higher clock rate further into the chain. As such, your approach with detecting the rising edge makes perfect sense. There is no need for the second register set.
> 
> What I was referring to had the presumption that it is/was desired to transition to the slower clock. For example, perhaps right after the de-serializer. Because the de-serializer is always working when the link is active and because there is a phase shift relative to the slower clock, it is necessary to additionally register right after the de-serializer to permit alignment to the slower clock while at the same time not dropping or losing anything.
> 
> Also note, that my comment about the DCM was backwards. I meant to mention a 1:7 not 7:1. For some reason I got on a 7:1 track. Woops. To pull off a 1:7  will require 2 DCMs. The first operates in a mode to permit a lower (than 32MHz) CLKIN frequency but outputs (a) a CLKFX higher frequency clock compatible with the second DCM and (b) a regenerated slower clock. The second DCM receives the now compatible clock from the first DCM and creates the final overall 1:7.
> 
> Regards,
> Carlton

It's been a while since I did that part of the design, but my
recollection is that I gave up on the ISERDES and just ended
up using input DDR flops at 3.5x the word rate.  It was easier
than trying to decipher the bit-slip business when I have no
guaranteed pattern on the inputs (except the clock).  The
original design was implemented on Lattice ECP2 with their
4x gearbox and an output clock rate of 1.75x the word rate.
In any case I put the data into a long (56-bit) register
2 or 4 bits at a time in the incoming clock domain (3.5x
or 1.75x) and read it out 7 bits at a time with an unrelated
clock guaranteed to exceed the word rate (a sort of FIFO).
My design had six of these inputs, so I needed to conserve
clock resources as much as possible.  In V5, one PLL does
the work of 2 DCM's, and does it better with more jitter
tolerance and less output jitter.  In my case I needed to
deal with the full frequency range of Channel-Link or 20
to 85 MHz, which also requires using the DRP port of the
PLL to switch between high and low frequency range settings.
At the low end, the PLL works down to 19 MHz.  In any
case I didn't have the OP's problem of slow receivers because
I put the camera link input directly to the V5 with only
some ESD protection diodes in between.

Regards,
Gabor

Article: 153874
Subject: Re: Virtex 4 Cameralink DCM Limitation
From: "langwadt@fonz.dk" <langwadt@fonz.dk>
Date: Mon, 18 Jun 2012 14:30:38 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 18, 6:01=A0pm, carlton...@gmail.com wrote:
> Hi Gabor,
>
> If I understand your approach correctly, you are using the higher clock r=
ate further into the chain. As such, your approach with detecting the risin=
g edge makes perfect sense. There is no need for the second register set.
>
> What I was referring to had the presumption that it is/was desired to tra=
nsition to the slower clock. For example, perhaps right after the de-serial=
izer. Because the de-serializer is always working when the link is active a=
nd because there is a phase shift relative to the slower clock, it is neces=
sary to additionally register right after the de-serializer to permit align=
ment to the slower clock while at the same time not dropping or losing anyt=
hing.
>
> Also note, that my comment about the DCM was backwards. I meant to mentio=
n a 1:7 not 7:1. For some reason I got on a 7:1 track. Woops. To pull off a=
 1:7 =A0will require 2 DCMs. The first operates in a mode to permit a lower=
 (than 32MHz) CLKIN frequency but outputs (a) a CLKFX higher frequency cloc=
k compatible with the second DCM and (b) a regenerated slower clock. The se=
cond DCM receives the now compatible clock from the first DCM and creates t=
he final overall 1:7.
>
> Regards,
> Carlton

can't you just generate the 7x clock with clkfx of single dcm?

shift data and clock in to regsister on that 7x clk, look for the
transition
on clock move the right bits from the shifter to a register
generate your slow clock with a divider aligned with the data update

-Lasse



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