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
2019JanFebMar2019

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 155650

Article: 155650
Subject: Re: Lattice Announces EOL for XP and EC/P Product Lines
From: rickman <gnuarm@gmail.com>
Date: Wed, 31 Jul 2013 17:32:55 -0400
Links: << >>  << T >>  << A >>
On 7/31/2013 5:13 PM, GaborSzakacs wrote:
>
> Most recent parts from Xilinx including Spartan 3A have SPI master
> mode configuration, requiring nothing extra over the SPI flash itself
> and a handful of resistors. Indirect SPI flash programming over
> JTAG is supported by Impact, and you can generate SVF files to
> do the programming with an embedded processor. Also because the
> pins used for SPI config become I/O after config, you can use
> the SPI flash in your design, and possibly come up with a more
> "native" solution to field updates (without using JTAG).

I'm not sure what the use of Impact implies.  Does that mean connecting 
a PC with a dongle cable?  That would be used in the factory perhaps, 
but in the field they want to use an CPU to drive the JTAG signals. 
They have that working for an Altera part, but not yet for the Lattice 
part and of course not for any Xilinx parts.

-- 

Rick

Article: 155651
Subject: Re: serial protocol specs and verification
From: alb <alessandro.basili@cern.ch>
Date: Wed, 31 Jul 2013 23:37:59 +0200
Links: << >>  << T >>  << A >>
On 31/07/2013 13:44, rickman wrote:
[]
>> <neatpick mode on>
>> Nyquist criterion has nothing to do with being able to sample data. As a
>> matter of fact your internal clock is perfectly capable to sample data
>> flowing in your fpga without the need to be 2x the data rate.
>> <neatpick mode off>
> 
> I don't know what you are talking about.  If you asynchronously sample,
> you very much do have to satisfy the Nyquist criterion.  A 2x clock,
> because it isn't *exactly* 2x, can *not* be used to capture a bitstream
> so that you can find the the transitions and know which bit is which.

A data stream which is *exactly* flowing with a frequency f can be
*exactly* sampled with a clock frequency f, it happens continuously in
your synchronous logic. What happened to Nyquist theorem?

If you have a protocol with data and clock, does it mean that you will
recognize only half of the bits because your clock rate is just equal to
your data rate? I'm confused...

IMO calling a signal 'asynchronous' does not make any difference. Mr.
Nyquist referred to reconstructing an analog signal with a discrete
sampling (no quantization error involved). How does that applies to
digital transmission?

> Otherwise there wouldn't be so many errors in the existing circuit.

It does not work not because of Nyquist limit, but because the recovery
of a phase shift cannot be done with just two clocks per bit.

[]
> You can use the FPGA PLL to multiply your clock from 2x to 4x to allow
> the DPLL to work correctly.

This is what I meant indeed. I believe I confused DPLL with ADPLL...


Article: 155652
Subject: Re: serial protocol specs and verification
From: langwadt@fonz.dk
Date: Wed, 31 Jul 2013 15:03:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Wednesday, July 31, 2013 11:37:59 PM UTC+2, alb wrote:
> On 31/07/2013 13:44, rickman wrote:
> 
> []
> 
> >> <neatpick mode on>
> 
> >> Nyquist criterion has nothing to do with being able to sample data. As a
> 
> >> matter of fact your internal clock is perfectly capable to sample data
> 
> >> flowing in your fpga without the need to be 2x the data rate.
> 
> >> <neatpick mode off>
> 
> > 
> 
> > I don't know what you are talking about.  If you asynchronously sample,
> 
> > you very much do have to satisfy the Nyquist criterion.  A 2x clock,
> 
> > because it isn't *exactly* 2x, can *not* be used to capture a bitstream
> 
> > so that you can find the the transitions and know which bit is which.
> 
> 
> 
> A data stream which is *exactly* flowing with a frequency f can be
> 
> *exactly* sampled with a clock frequency f, it happens continuously in
> 
> your synchronous logic. What happened to Nyquist theorem?
> 
> 
> 
> If you have a protocol with data and clock, does it mean that you will
> 
> recognize only half of the bits because your clock rate is just equal to
> 
> your data rate? I'm confused...
> 
> 
> 
> IMO calling a signal 'asynchronous' does not make any difference. Mr.
> 
> Nyquist referred to reconstructing an analog signal with a discrete
> 
> sampling (no quantization error involved). How does that applies to
> 
> digital transmission?
> 
> 
> 
> > Otherwise there wouldn't be so many errors in the existing circuit.
> 
> 
> 
> It does not work not because of Nyquist limit, but because the recovery
> 
> of a phase shift cannot be done with just two clocks per bit.
> 

may not technically be Nyquist limit, but like so many things in nature the
same relations are repeated 

and if you take NRZ you'll notice that the highest "frequency" (0101010101..)
is only half of the data rate

-Lasse

Article: 155653
Subject: Re: serial protocol specs and verification
From: alb <alessandro.basili@cern.ch>
Date: Thu, 01 Aug 2013 00:19:43 +0200
Links: << >>  << T >>  << A >>
On 31/07/2013 15:36, RCIngham wrote:
> [snip]
>>
>> A frame is defined as follows:
>>
>> - sync  :'111'
>> - header: dtype (4) - n.u.(2) - length (10)
>> - data  : (16) * length
>>
>> in principle between frames there can be any number of zeros (with bit
>> stuffing). An 'all zero' pattern in this sense might be of any number of
>> bits.
>>
> [snip]
> 
> Unless 'length' is limited, your worst case has header "0000001111111111"
> (with an extra bit stuffed) followed by 16 * 1023 = 16368 zeros, which will
> have 2728 ones stuffed into them. Total line packet length is 19113
> symbols. 

Why you excluded the sync symbol?

If the clocks are within 1/19114 of each other, the same number of
> symbols will be received as sent, ASSUMING no jitter.

5*10e-5 is a very large difference. We are using 0.5 ppm oscillators.
The amount of symbols received has to take into account phase shift
otherwise bits will be lost or oversampled.

> You can't assume
> that, but if there is 'not much' jitter then perhaps 1/100k will be good
> enough for relative drift to not need to be corrected for.

Still not sure what you are trying to say.

> So, for version 1, use the 'sync' to establish the start of frame and the
> sampling point, simulate the 'Rx fast' and 'Rx slow' cases in parallel, and
> see whether it works.

by saying 'in parallel' you mean a data stream with some bits slower and
some faster?
I think the main problem lies on the slight difference in clock
frequencies which lead to increasing phase shift to the point where a
bit is lost or oversampled.

> 
> BTW, this is off-topic for C.A.F., as it is a system design problem not
> related to the implementation method.

IMO is an implementation issue, no specs will tell me how many times I
need to sample the data stream. The system design does not have a
problem IMO, it simply specify the protocol between two modules. But I
will be more than happy if you could point me out to some more
appropriate group.

Article: 155654
Subject: Re: Lattice Announces EOL for XP and EC/P Product Lines
From: Jon Elson <jmelson@wustl.edu>
Date: Wed, 31 Jul 2013 17:23:31 -0500
Links: << >>  << T >>  << A >>
rickman wrote:


> I'm not sure what the use of Impact implies.  Does that mean connecting
> a PC with a dongle cable?  That would be used in the factory perhaps,
> but in the field they want to use an CPU to drive the JTAG signals.
> They have that working for an Altera part, but not yet for the Lattice
> part and of course not for any Xilinx parts.
> 
Yes, you certainly can do that, and Xilinx has some articles
on how to write your computer code to take a .bit file loaded into
a processor's EPROM and perform the various modes of download
available.  There is serial config, parallel config, JTAG config,
etc.  To do this from a CPU, you want slave mode, where the
CPU clocks the bits into the FPGA.  For a serial EPROM chip you
select master serial, so the FPGA generates the bit clock.
The newer FPGAs have almost too MANY modes of configuration.

Jon

Article: 155655
Subject: Re: Lattice Announces EOL for XP and EC/P Product Lines
From: Chris <catalsma@gmail.com>
Date: Wed, 31 Jul 2013 16:48:00 -0700 (PDT)
Links: << >>  << T >>  << A >>
Rick... I check the Actel/Microsemi lead you started down on the original p=
ost, they have options available in your target size, 100 pin QFP, are flas=
h based/reprogrammable over JTAG and I think should have very similar power=
 requirements to your original design.  I am looking at this chip, availabl=
e today on digikey: AGL250V2-VQG100, 14 mm2, $25.40, 68 I/O and a fair amou=
nt of logic.  If you don't need that much logic and want a cheaper part the=
y go down from there in the same package.

Article: 155656
Subject: Re: serial protocol specs and verification
From: Richard Damon <Richard@Damon-Family.org>
Date: Thu, 01 Aug 2013 00:28:13 -0400
Links: << >>  << T >>  << A >>
On 7/31/13 9:36 AM, RCIngham wrote:
> [snip]
>>
> Unless 'length' is limited, your worst case has header "0000001111111111"
> (with an extra bit stuffed) followed by 16 * 1023 = 16368 zeros, which will
> have 2728 ones stuffed into them. Total line packet length is 19113
> symbols. If the clocks are within 1/19114 of each other, the same number of
> symbols will be received as sent, ASSUMING no jitter. You can't assume
> that, but if there is 'not much' jitter then perhaps 1/100k will be good
> enough for relative drift to not need to be corrected for.
> 
> So, for version 1, use the 'sync' to establish the start of frame and the
> sampling point, simulate the 'Rx fast' and 'Rx slow' cases in parallel, and
> see whether it works.
> 
> BTW, this is off-topic for C.A.F., as it is a system design problem not
> related to the implementation method.
> 	   
> 

Since you can resynchronize your sampling clock on each transition
received, you only need to "hold lock" for the maximum time between
transitions, which is 7 bit times. This would mean that if you have a
nominal 4x clock, some sample points will be only 3 clocks apart (if you
are slow) or some will be 5 clocks apart (if you are fast), while most
will be 4 clock apart. This is the reason for the 1 bit stuffing.


Article: 155657
Subject: Re: Lattice Announces EOL for XP and EC/P Product Lines
From: Svenn Are Bjerkem <svenn.bjerkem@googlemail.com>
Date: Thu, 1 Aug 2013 00:21:08 -0700 (PDT)
Links: << >>  << T >>  << A >>
kl. 00:54:41 UTC+2 wednesday 31. july 2013 rickman wrote:
> In fact, I'm skipping Altera for the moment and skipping over to=20
> MicroSemi and Cypress to see if their combination CPU/Logic devices=20
> might do the job well and let me eliminate the stereo CODEC to (another=
=20
> part that could go obsolete at any time).  I seem to recall that the=20
> Cypress part might be just the ticket but the MicroSemi part runs some=20
> $50 at the low point.  The current Lattice part is running under $10.

We've got a quote for the Microsemi SF2 M2S010 (without T) somewhere in the=
 middle of that price difference in low volume. The features of SF2 somehow=
 justified the additional price because we could avoid a separate flash and=
 MCU externally. The flexibility in configuration of the FPGA and MSS and h=
ard preipherals also give us design freedom. Low power consumption was defi=
nitively something worth a bit extra.

--=20
Svenn

Article: 155658
Subject: Re: serial protocol specs and verification
From: "RCIngham" <2161@embeddedrelated>
Date: Thu, 01 Aug 2013 04:56:01 -0500
Links: << >>  << T >>  << A >>
>On 7/31/13 9:36 AM, RCIngham wrote:
>> [snip]
>>>
>> Unless 'length' is limited, your worst case has header
"0000001111111111"
>> (with an extra bit stuffed) followed by 16 * 1023 = 16368 zeros, which
will
>> have 2728 ones stuffed into them. Total line packet length is 19113
>> symbols. If the clocks are within 1/19114 of each other, the same number
of
>> symbols will be received as sent, ASSUMING no jitter. You can't assume
>> that, but if there is 'not much' jitter then perhaps 1/100k will be
good
>> enough for relative drift to not need to be corrected for.
>> 
>> So, for version 1, use the 'sync' to establish the start of frame and
the
>> sampling point, simulate the 'Rx fast' and 'Rx slow' cases in parallel,
and
>> see whether it works.
>> 
>> BTW, this is off-topic for C.A.F., as it is a system design problem not
>> related to the implementation method.
>> 	   
>> 
>
>Since you can resynchronize your sampling clock on each transition
>received, you only need to "hold lock" for the maximum time between
>transitions, which is 7 bit times. This would mean that if you have a
>nominal 4x clock, some sample points will be only 3 clocks apart (if you
>are slow) or some will be 5 clocks apart (if you are fast), while most
>will be 4 clock apart. This is the reason for the 1 bit stuffing.
>

The bit-stuffing in long sequences of zeroes is almost certainly there to
facilitate a conventional clock recovery method, which I am proposing not
using PROVIDED THAT the clocks at each end are within a sufficiently tight
tolerance. Detect the ones in the as-sent stream first, then decide which
are due to bit-stuffing, and remove them.

Deciding how tight a tolerance is 'sufficiently tight' is probably
non-trivial, so I won't be doing it for free.
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 155659
Subject: Re: seperate high speed rules for HDL?
From: "RCIngham" <2161@embeddedrelated>
Date: Thu, 01 Aug 2013 05:08:34 -0500
Links: << >>  << T >>  << A >>
>On Wednesday, July 31, 2013 9:22:53 PM UTC+2, glen herrmannsfeldt wrote:
>> langwadt@fonz.dk wrote:
>> 
>> (snip, someone wrote)
>> 
>> >> Zero (or less) hold time on FFs is not true for all FPGAs. 
>> >> It also does not account for finite skew between clock 
>> >> arrival at different FFs, even using a "global clock net".
>> 
>> > then the tools better hide that if you want to use it for anything
>> > if you don't have zero hold you can't tell if the path between 
>> > two FFs might happen to be less that the required hold and if you 
>> > could what would you do? insert some dummy logic to add some delay?
>> 
>> The FF's don't have to have zero hold time, they just have to
>> have a hold time less than the shortest route between a previous FF.
>> 
>> I remember in the TTL days, with zero hold time one could wire 
>> from one output pin to an input, such as Qbar to D. That was
>> guaranteed to work.
>> 
>> In the case of FGPAs, though, you have the FPGA routine fabric
>> to go through. There will be a minimum length route.
>> 
>> > and if you can't assume the the skew is effectively zero how 
>> > are you going to do a synchronous design?  
>> 
>> Well, again, if the clock skew plus hold time is less than the
>> minimum length route, you won't notice it. 
>> 
>> For some FPGA families and tools, one can hand route at least
>> some signals. If there was a possible route faster than skew
>> plus hold, the data sheet should tell you about it.
>> 
>> -- glen
>
>
>what I mean isn't that hold and skew should literally have 
>to be zero but it should be so that you can design as if it 
>was and it is guaranteed to work
>
>
>-Lasse
>

What the OP should do is a trial fully-synchronous design, run it all the
way through the tools, and see whether the Static Timing Analysis shows
that it is "fast enough". If not, start adding pipelining stages in the
areas that are causing a problem.

The major vendors' toolsets are all quite good at optimising for speed in
fully-synchronous datapath designs (although I have had various problems
with Virtex-5 parts in the past).
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 155660
Subject: Re: serial protocol specs and verification
From: alb <alessandro.basili@cern.ch>
Date: Thu, 01 Aug 2013 14:55:38 +0200
Links: << >>  << T >>  << A >>
On 01/08/2013 11:56, RCIngham wrote:
[]
>> Since you can resynchronize your sampling clock on each transition
>> received, you only need to "hold lock" for the maximum time between
>> transitions, which is 7 bit times. This would mean that if you have a
>> nominal 4x clock, some sample points will be only 3 clocks apart (if you
>> are slow) or some will be 5 clocks apart (if you are fast), while most
>> will be 4 clock apart. This is the reason for the 1 bit stuffing.
>>
> 
> The bit-stuffing in long sequences of zeroes is almost certainly there to
> facilitate a conventional clock recovery method, which I am proposing not
> using PROVIDED THAT the clocks at each end are within a sufficiently tight
> tolerance. Detect the ones in the as-sent stream first, then decide which
> are due to bit-stuffing, and remove them.

What is the gain of not using 'conventional clock recovery'?

Article: 155661
Subject: Re: seperate high speed rules for HDL?
From: jonesandy@comcast.net
Date: Thu, 1 Aug 2013 12:11:43 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Wednesday, July 31, 2013 3:59:49 PM UTC-5, lang...@fonz.dk wrote:
> what I mean isn't that hold and skew should literally have to be zero but it should be so that you can design as if it was and it is guaranteed to work -Lasse

In the case of Microsemi PA3E devices, their place & route tool works to solve any hold times for you, assuming you enable that setting. I have seen several hold time violations with that setting disabled, but not with the setting enabled.

Andy

Article: 155662
Subject: NiosII 8.0 make error Windows XP
From: Vivek Menon <vivek.menon79@gmail.com>
Date: Thu, 1 Aug 2013 12:48:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
I am trying to build a simple hello world example using Nios II v8.0 on a w=
indows Xp machine.

I see the following errors:

**** Build of configuration Debug for project LIDAR_NIOSII_USB2 ****make -s=
 all includes make: /bin/sh.exe: Command not foundmake: /bin/sh.exe: Comman=
d not foundmake: /bin/sh.exe: Command not foundmake: /bin/sh.exe: Command n=
ot foundmake: /bin/sh.exe: Command not foundC:/altera/80/nios2eds/component=
s/altera_hal/build/app_rules.mk:153: /components/altera_hal/build/gnu_rules=
.mk: No such file or directoryC:/altera/80/nios2eds/components/altera_hal/b=
uild/app_rules.mk:157: /components/altera_hal/build/gtf_rules.mk: No such f=
ile or directorymake: *** No rule to make target `/components/altera_hal/bu=
ild/gtf_rules.mk'. Stop.Build completed in 0.563 seconds

I have my SOPC_KIT_NIOS2 path set to C:\altera\80\nios2eds

Any suggestions??

Article: 155663
Subject: Re: seperate high speed rules for HDL?
From: langwadt@fonz.dk
Date: Thu, 1 Aug 2013 14:39:54 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Thursday, August 1, 2013 9:11:43 PM UTC+2, jone...@comcast.net wrote:
> On Wednesday, July 31, 2013 3:59:49 PM UTC-5, lang...@fonz.dk wrote:
> 
> > what I mean isn't that hold and skew should literally have to be zero but it should be so that you can design as if it was and it is guaranteed to work -Lasse
> 
> 
> 
> In the case of Microsemi PA3E devices, their place & route tool works to solve any hold times for you, assuming you enable that setting. I have seen several hold time violations with that setting disabled, but not with the setting enabled.
> 
> 
> Andy

how does that work? I mean if you don't enable that option and get a hold  violation what can you do? can't just start adding random logic hoping it 
fixes the problem


-Lasse

Article: 155664
Subject: Re: seperate high speed rules for HDL?
From: gtwrek@sonic.net (Mark Curry)
Date: Thu, 1 Aug 2013 23:59:55 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <26bc041f-8f5c-49af-afc6-0c47c124e5f9@googlegroups.com>,
 <langwadt@fonz.dk> wrote:
>On Thursday, August 1, 2013 9:11:43 PM UTC+2, jone...@comcast.net wrote:
>> On Wednesday, July 31, 2013 3:59:49 PM UTC-5, lang...@fonz.dk wrote:
>> 
>> > what I mean isn't that hold and skew should literally have to bei
>> > zero but it should be so that
>> >you can design as if it was and it is guaranteed to work -Lasse

>> 
>> In the case of Microsemi PA3E devices, their place & route tool works 
>> to solve any hold times for you, assuming you enable that setting. 
>> I have seen several hold time violations with that
>> setting disabled, but not with the setting enabled.
>
>how does that work? I mean if you don't enable that option and 
>get a hold  violation what can you do? can't just start adding 
> random logic hoping it fixes the problem

The tool solves hold times buy just adding delay to the datapath.  
Xilinx tools fix hold times too.  Or am I misunderstanding your 
question?  It's on by default - don't even know if you can turn 
it off.

Regards,

Mark


Article: 155665
Subject: Re: serial protocol specs and verification
From: rickman <gnuarm@gmail.com>
Date: Fri, 02 Aug 2013 00:16:51 -0400
Links: << >>  << T >>  << A >>
On 8/1/2013 8:55 AM, alb wrote:
> On 01/08/2013 11:56, RCIngham wrote:
> []
>>> Since you can resynchronize your sampling clock on each transition
>>> received, you only need to "hold lock" for the maximum time between
>>> transitions, which is 7 bit times. This would mean that if you have a
>>> nominal 4x clock, some sample points will be only 3 clocks apart (if you
>>> are slow) or some will be 5 clocks apart (if you are fast), while most
>>> will be 4 clock apart. This is the reason for the 1 bit stuffing.
>>>
>>
>> The bit-stuffing in long sequences of zeroes is almost certainly there to
>> facilitate a conventional clock recovery method, which I am proposing not
>> using PROVIDED THAT the clocks at each end are within a sufficiently tight
>> tolerance. Detect the ones in the as-sent stream first, then decide which
>> are due to bit-stuffing, and remove them.
>
> What is the gain of not using 'conventional clock recovery'?

I think the point is that if the sequences are short enough that the 
available timing tolerance is adequate, then you just don't need to 
recover timing from the bit stream.

I've been looking at this, then working on other issues and have lost my 
train of thought on this.  I believe that a PLL (or DPLL) is not needed 
as long as the input can be sampled fast enough and the reference 
frequency is matched closely enough.  But it is still important to 
correct for "phase" as the OP puts it (IIRC) so that you can tell where 
the bits are and not sample on transitions, just like a conventional 
UART does it.  We frequent enough transitions, the phase can be detected 
and aligned while the exact frequency does not need to be recovered.

-- 

Rick

Article: 155666
Subject: Re: serial protocol specs and verification
From: rickman <gnuarm@gmail.com>
Date: Fri, 02 Aug 2013 00:19:10 -0400
Links: << >>  << T >>  << A >>
On 7/31/2013 5:37 PM, alb wrote:
> On 31/07/2013 13:44, rickman wrote:
> []
>>> <neatpick mode on>
>>> Nyquist criterion has nothing to do with being able to sample data. As a
>>> matter of fact your internal clock is perfectly capable to sample data
>>> flowing in your fpga without the need to be 2x the data rate.
>>> <neatpick mode off>
>>
>> I don't know what you are talking about.  If you asynchronously sample,
>> you very much do have to satisfy the Nyquist criterion.  A 2x clock,
>> because it isn't *exactly* 2x, can *not* be used to capture a bitstream
>> so that you can find the the transitions and know which bit is which.
>
> A data stream which is *exactly* flowing with a frequency f can be
> *exactly* sampled with a clock frequency f, it happens continuously in
> your synchronous logic. What happened to Nyquist theorem?
>
> If you have a protocol with data and clock, does it mean that you will
> recognize only half of the bits because your clock rate is just equal to
> your data rate? I'm confused...
>
> IMO calling a signal 'asynchronous' does not make any difference. Mr.
> Nyquist referred to reconstructing an analog signal with a discrete
> sampling (no quantization error involved). How does that applies to
> digital transmission?

Yes, you are right about the rates.  I was not thinking of this 
correctly.  The Nyquist theorem looks at *frequency* content which is 
not the same as bit rate.


>> Otherwise there wouldn't be so many errors in the existing circuit.
>
> It does not work not because of Nyquist limit, but because the recovery
> of a phase shift cannot be done with just two clocks per bit.
>
> []
>> You can use the FPGA PLL to multiply your clock from 2x to 4x to allow
>> the DPLL to work correctly.
>
> This is what I meant indeed. I believe I confused DPLL with ADPLL...

I am not familiar with ADPLL.  What is that?

-- 

Rick

Article: 155667
Subject: Re: serial protocol specs and verification
From: Richard Damon <Richard@Damon-Family.org>
Date: Fri, 02 Aug 2013 00:22:27 -0400
Links: << >>  << T >>  << A >>
On 8/1/13 5:56 AM, RCIngham wrote:
>> On 7/31/13 9:36 AM, RCIngham wrote:
>>> [snip]
>>>>
>>> Unless 'length' is limited, your worst case has header
> "0000001111111111"
>>> (with an extra bit stuffed) followed by 16 * 1023 = 16368 zeros, which
> will
>>> have 2728 ones stuffed into them. Total line packet length is 19113
>>> symbols. If the clocks are within 1/19114 of each other, the same number
> of
>>> symbols will be received as sent, ASSUMING no jitter. You can't assume
>>> that, but if there is 'not much' jitter then perhaps 1/100k will be
> good
>>> enough for relative drift to not need to be corrected for.
>>>
>>> So, for version 1, use the 'sync' to establish the start of frame and
> the
>>> sampling point, simulate the 'Rx fast' and 'Rx slow' cases in parallel,
> and
>>> see whether it works.
>>>
>>> BTW, this is off-topic for C.A.F., as it is a system design problem not
>>> related to the implementation method.
>>> 	   
>>>
>>
>> Since you can resynchronize your sampling clock on each transition
>> received, you only need to "hold lock" for the maximum time between
>> transitions, which is 7 bit times. This would mean that if you have a
>> nominal 4x clock, some sample points will be only 3 clocks apart (if you
>> are slow) or some will be 5 clocks apart (if you are fast), while most
>> will be 4 clock apart. This is the reason for the 1 bit stuffing.
>>
> 
> The bit-stuffing in long sequences of zeroes is almost certainly there to
> facilitate a conventional clock recovery method, which I am proposing not
> using PROVIDED THAT the clocks at each end are within a sufficiently tight
> tolerance. Detect the ones in the as-sent stream first, then decide which
> are due to bit-stuffing, and remove them.
> 
> Deciding how tight a tolerance is 'sufficiently tight' is probably
> non-trivial, so I won't be doing it for free.
> 	   
> 

Since a 4x clock allows for a 25% data period correction, and we will
get an opportunity to do so every 7 data periods, we can tolerate about
a 25/7 ~ 3% error in clock frequency. (To get a more exact value we will
need to know details like jitter and sampling apertures, but this gives
us a good ball-park figure). Higher sampling rates can about double
this, the key is we need to be able to know which direction the error is
in, so we need to be less than a 50% of a data period error including
the variation within a sample clock.

To try to gather the data without resynchronizing VASTLY decreases your
tolerance for clock errors as you need to stay within a clock cycle over
the entire message.

The protocol, with its 3 one preamble, does seem like there may have
been some effort to enable the use of a PLL to generate the data
sampling clock, which may have been the original method. This does have
the advantage the the data clock out of the sampler is more regular (not
having the sudden jumps from the resyncronizing), and getting a set a
burst of 1s helps the PLL to get a bit more centered on the data. My
experience though is that with FPGAs (as would be on topic for this
group), this sort of PLL synchronism is not normally used, but
oversampling clocks with phase correction is fairly standard.


Article: 155668
Subject: Re: Lattice Announces EOL for XP and EC/P Product Lines
From: rickman <gnuarm@gmail.com>
Date: Fri, 02 Aug 2013 00:32:35 -0400
Links: << >>  << T >>  << A >>
On 8/1/2013 3:21 AM, Svenn Are Bjerkem wrote:
> kl. 00:54:41 UTC+2 wednesday 31. july 2013 rickman wrote:
>> In fact, I'm skipping Altera for the moment and skipping over to
>> MicroSemi and Cypress to see if their combination CPU/Logic devices
>> might do the job well and let me eliminate the stereo CODEC to (another
>> part that could go obsolete at any time).  I seem to recall that the
>> Cypress part might be just the ticket but the MicroSemi part runs some
>> $50 at the low point.  The current Lattice part is running under $10.
>
> We've got a quote for the Microsemi SF2 M2S010 (without T) somewhere in the middle of that price difference in low volume. The features of SF2 somehow justified the additional price because we could avoid a separate flash and MCU externally. The flexibility in configuration of the FPGA and MSS and hard preipherals also give us design freedom. Low power consumption was definitively something worth a bit extra.

Yes, each project has its own requirements so some will justify a higher 
price for the improved integration.  I am not so familiar with the 
Microsemi part and I not had time to dig into their offerings.  I don't 
even know if they have anything new in the last year or two.

The main stumbling block for the Cypress part is the lack of CD quality 
CODEC I believe.  But that is only a $3 part at most.  There are also 
some op amps on the board which I doubt can be replaced since at least 
four of them are used to drive a 12 volt supply into a 50 ohm load (8 
Vp-p IIRC).  The remaining parts are analog switches on the analog I/O, 
analog switches on the digital I/O to act as 5-3 volt level converters 
and a two channel RS-422 input/output chip.  I doubt any of this can be 
pulled into the Microsemi part leaving us with this possibly replacing 
the existing FPGA and the CODEC at best.  So it would be hard to justify 
replacing what is otherwise $15 worth of parts with a $30 part if I read 
your post correctly.  By low volume I assume you mean qty 100 ball park.

Funny about Cypress.  I seem to recall their web site having gone 
downhill over the last few years.  When I tried to download a data sheet 
on their parts I couldn't find one!  They have links for their software 
and for samples, but none for a data sheet!!!?  Maybe it is embedded in 
their development software?  They also give a crappy overview of their 
parts.  So far I haven't figured it out but I guess it is worth a second 
try.

-- 

Rick

Article: 155669
Subject: Re: Lattice Announces EOL for XP and EC/P Product Lines
From: rickman <gnuarm@gmail.com>
Date: Fri, 02 Aug 2013 00:37:11 -0400
Links: << >>  << T >>  << A >>
On 7/31/2013 6:23 PM, Jon Elson wrote:
> rickman wrote:
>
>
>> I'm not sure what the use of Impact implies.  Does that mean connecting
>> a PC with a dongle cable?  That would be used in the factory perhaps,
>> but in the field they want to use an CPU to drive the JTAG signals.
>> They have that working for an Altera part, but not yet for the Lattice
>> part and of course not for any Xilinx parts.
>>
> Yes, you certainly can do that, and Xilinx has some articles
> on how to write your computer code to take a .bit file loaded into
> a processor's EPROM and perform the various modes of download
> available.  There is serial config, parallel config, JTAG config,
> etc.  To do this from a CPU, you want slave mode, where the
> CPU clocks the bits into the FPGA.  For a serial EPROM chip you
> select master serial, so the FPGA generates the bit clock.
> The newer FPGAs have almost too MANY modes of configuration.

I think what you are describing is rather different.  This is the slave 
serial config mode which is somewhat limited in functionality.  The 
interface my customer has provided is intended to use a JTAG interface. 
  In the case of the serial EEPROM the CPU would either program the 
EEPROM directly or drive the JTAG on the FPGA to program the EEPROM.

I'm pretty sure the customer does *not* want to load the part every time 
it is booted, just once in a programming mode, then the board loads 
itself when it boots up.  I'm not sure if this is what you were 
describing or not.

-- 

Rick

Article: 155670
Subject: Re: serial protocol specs and verification
From: alb <alessandro.basili@cern.ch>
Date: Fri, 02 Aug 2013 09:49:20 +0200
Links: << >>  << T >>  << A >>
On 02/08/2013 06:19, rickman wrote:
[]
>>
>> This is what I meant indeed. I believe I confused DPLL with ADPLL...
> 
> I am not familiar with ADPLL.  What is that?

It is an All Digital PLL:

http://www.aicdesign.org/2003%20PLL%20Slides/L050-ADPLLs-2UP(9_1_03).pdf

all the elements of a PLL are implemented in the digital domain.

Article: 155671
Subject: Re: serial protocol specs and verification
From: alb <alessandro.basili@cern.ch>
Date: Fri, 02 Aug 2013 10:33:06 +0200
Links: << >>  << T >>  << A >>
Hi Lasse,

On 01/08/2013 00:03, langwadt@fonz.dk wrote:
[]
>> It does not work not because of Nyquist limit, but because the 
>> recovery
>> 
>> of a phase shift cannot be done with just two clocks per bit.
>> 
> 
> may not technically be Nyquist limit, but like so many things in 
> nature the same relations are repeated

A signal traveling on a physical channel (be it on a cable, a PCB route,
an FPGA interconnection...) will have sharp transitions at the beginning
of its journey and sloppier ones at the end due to losses, but if you
take a comparator and discriminate a '1' or '0', then you do not 'need'
higher frequencies than half the data rate itself (or symbol rate to be
precise). If you take a sinusoidal waveform and put a threshold at 0,
then you have two symbols per cycle.

Why sampling at the data rate is not sufficient then? Because there are
several other factors. First of all encoding and decoding are processes
which do introduce 'noise' as well as 'limitations'. Having a comparator
to discriminate 0/1 does introduce noise in the time of transaction,
therefore distorting the phase of the signal. The medium itself might be
source of other jitter since it is sensitive to the environment
(temperature, pressure, humidity, ...).


     TRANSMITTER        MEDIUM          RECEIVER
+-------------------+            +-------------------+
|               +---|            |---+               |
| '10100101' -> |ENC| -\/\/\/\/->|DEC| -> '10101110' |
|               +---|  physical  |---+               |
+-------------------+   signal   +-------------------+
          ^                                 ^
          |                                 |
       +-----+                           +-----+
       | clk |                           | clk |
       +-----+                           +-----+

You do not care about reconstructing a physical signal (like in ADC
sampling), you *do* care about reconstructing a data stream.
Another source of troubles are the two clock generators on the TX and
RX. They cannot be assumed to be perfectly matching and any difference
will lead to a phase drift which eventually will spoil your data sampling.

> and if you take NRZ you'll notice that the highest "frequency" 
> (0101010101..) is only half of the data rate

that is why a clock frequency = to data rate is sufficient to 'sample'
the information.

<nitpick mode on>
the NRZ is a line code, i.e. a translation of your data stream with
appropriate physical signal (light, current, sound, ...) for the chosen
physical medium (fiber, cable, air, ...) and has nothing to do with a
toggling bit.
<nitpick mode off>

Article: 155672
Subject: Parallella-16 lowest-cost xilinx zynq kit
From: acd <acd4usenet@lycos.de>
Date: Fri, 2 Aug 2013 01:59:14 -0700 (PDT)
Links: << >>  << T >>  << A >>
The crowdfunded Parallella-16  starter kit from adapteva 
seems to be the lowest-cost xilinx zynq starter kit at the same time. 
For USD 99 one gets a  XC7Z010 board with 1GB DRAM, GB Ethernet, Flash, USB, 
and the 16-core epiphany processor. 

But of course, one could use the FPGA only. 

Andreas

(I pre-ordered mine last week, I am not associated with the project or with Adapteva).

Article: 155673
Subject: Re: serial protocol specs and verification
From: alb <alessandro.basili@cern.ch>
Date: Fri, 02 Aug 2013 12:30:05 +0200
Links: << >>  << T >>  << A >>
Hi Richard,

On 02/08/2013 06:22, Richard Damon wrote:
[]
>> The bit-stuffing in long sequences of zeroes is almost certainly there to
>> facilitate a conventional clock recovery method, which I am proposing not
>> using PROVIDED THAT the clocks at each end are within a sufficiently tight
>> tolerance. Detect the ones in the as-sent stream first, then decide which
>> are due to bit-stuffing, and remove them.
>>
>> Deciding how tight a tolerance is 'sufficiently tight' is probably
>> non-trivial, so I won't be doing it for free.
>> 	   
>>
> 
> Since a 4x clock allows for a 25% data period correction, and we will
> get an opportunity to do so every 7 data periods, we can tolerate about
> a 25/7 ~ 3% error in clock frequency. (To get a more exact value we will
> need to know details like jitter and sampling apertures, but this gives
> us a good ball-park figure). Higher sampling rates can about double
> this, the key is we need to be able to know which direction the error is
> in, so we need to be less than a 50% of a data period error including
> the variation within a sample clock.

According to your math it looks like a 2x clock allows for a 50% data
period correction and therefore a 50/7 ~6% error in clock frequency,
which seems to me quite counter intuitive... Am I missing something?

[]
> The protocol, with its 3 one preamble, does seem like there may have
> been some effort to enable the use of a PLL to generate the data
> sampling clock, which may have been the original method. This does have
> the advantage the the data clock out of the sampler is more regular (not
> having the sudden jumps from the resyncronizing), and getting a set a
> burst of 1s helps the PLL to get a bit more centered on the data. My
> experience though is that with FPGAs (as would be on topic for this
> group), this sort of PLL synchronism is not normally used, but
> oversampling clocks with phase correction is fairly standard.

This is indeed what I'm looking for, oversampling (4x or 8x) and phase
correct.


Article: 155674
Subject: Re: Lattice Announces EOL for XP and EC/P Product Lines
From: Anssi Saari <as@sci.fi>
Date: Fri, 02 Aug 2013 13:31:25 +0300
Links: << >>  << T >>  << A >>
GaborSzakacs <gabor@alacron.com> writes:

> I'm pretty sure that the 144-pin package is the smallest with flash.

The data sheet lists Spartan3 200AN and 50AN parts with VQ100 package
and 68 user I/Os. Might be those packages are EOL though.



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
2019JanFebMar2019

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