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 155625

Article: 155625
Subject: Re: Lattice Announces EOL for XP and EC/P Product Lines
From: rickman <gnuarm@gmail.com>
Date: Tue, 30 Jul 2013 18:40:20 -0400
Links: << >>  << T >>  << A >>
On 7/30/2013 5:11 PM, Theo Markettos wrote:
> already5chosen@yahoo.com wrote:
>> If "nice" = 100 pin QFP, then yes, except for ancient Cyclone-I, Altera
>> does not have anything nice.
>>
>> But if 144 pin QFP is also o.k. then there are relatively modern Cyclone
>> III devices.  Voltage and the rest is more or less the same as Xilinx.
>
> There's some Cyclone IVs in 144ish QFP too.

I would love to use a 144 pin QFP, but they don't fit on the board.  It 
is a very narrow daughtercard, only 0.85" wide and the 144 QFP is 0.86" 
wide without counting the pad over hang.  A 17x17mm 256 BGA is the best 
of the rest so far.  It has a 1 mm pitch although I haven't looked at 
what it takes to get vias between the balls.  I expect I will need to be 
willing to push below the comfort zone of 6/6 mil space/trace and maybe 
below 10 mil drill.

One nice thing about the 256 BGA is that I only need to reach the power 
and ground pins and the outer ring or two to get my 62 I/Os.  I can 
ignore the rest of the balls.

-- 

Rick

Article: 155626
Subject: Re: Lattice Announces EOL for XP and EC/P Product Lines
From: rickman <gnuarm@gmail.com>
Date: Tue, 30 Jul 2013 18:45:47 -0400
Links: << >>  << T >>  << A >>
On 7/30/2013 3:50 PM, Jon Elson wrote:
> rickman wrote:
>
>
>> The Xilinx parts are interesting.  Spartan 3 devices come in 100 QFPs
>> and have enough of the "right stuff" inside including multipliers which
>> I can use.  But that external flash needs a spot on the board and I have
>> to use a 1.2 volt regulator for the core.  The XP parts use an internal
>> regulator and run from 3.3 volts only.  Xilinx has a rep for keeping
>> parts in production for a long, long time, but the S3 line came out in
>> 2005, same as the XP line.  Spartan 6 parts give a *lot* more
>> functionality, but I'd have to use a 256 pin 1.0 mm BGA *and* external
>> flash *and* the 1.2 volt supply *and* they are twice the price.  Maybe
>> I'll talk to the disties.  Maybe they can do something about the price
>> at least.
>>
> Spartan 3AN has internal flash.  I don't recall if there is a 100-pin
> version, I am using the 144-pin version in a couple products.
> I refuse to go to BGAs until there are no leaded parts remaining
> available.

No S3AN in 100 pin QFP, this may be because it is a dual die 
configuration or more likely they just don't expect to sell a lot of 
this size.  I haven't bothered to check the price either.  They do have 
a FTG256 which might do the job.  I expect I can find the space for a 
very small 8 pin flash part if I go QFN.  Again, I need to dig more. 
I've just started looking...

Actually my main concern with the external flash is the whole JTAG 
programming at the factory and/or lab thing, but there are likely many 
ways to deal with that including having them programmed before assembly. 
  It is just that I've been using these Flash FPGAs for some time now 
and I'm very used to them.

-- 

Rick

Article: 155627
Subject: Re: Lattice Announces EOL for XP and EC/P Product Lines
From: rickman <gnuarm@gmail.com>
Date: Tue, 30 Jul 2013 18:54:41 -0400
Links: << >>  << T >>  << A >>
On 7/30/2013 6:02 PM, Jon Elson wrote:
> GaborSzakacs wrote:
>
>
>> I'm pretty sure that the 144-pin package is the smallest with flash.
>> In any case it's not a big win over an external SPI flash part.  The
>> difference in footprint between 100 TQFP and 144 TQFP is more than
>> the flash footprint.  Not to mention there's a price premium for that
>> multi-die package.
>>
> Right, unless I have a pretty strong reason to use the 3AN, I use
> the Spartan 3, and the SST flash chips, which are insanely cheap.
> I wrote my own programmer code for those.  Spartan 2E needed some
> interface fooling around to command the memory to start dumping at
> location zero, but the 3A knows how to do it by setting some config
> pins.

This is the stuff I'm concerned about with the external flash.  But it 
is just a mater of figuring out how to do it and then doing that... Too 
bad I don't have space for an MCU.  The design could use one, but if it 
happens it will be *inside* the FPGA.  Just no board space at all.

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.

Although, if the CODEC could be absorbed inside an MCU, there is some 
board space at that point, about 6.5mm sq.  But how many MCUs can do 16 
bit, CD quality audio on two channels?  Maybe Analog Devices, but their 
MCU parts don't give me confidence in their longevity.  It also has to 
read the external flash and dump it into the FPGA so those tiny audio 
DSPs are out.

-- 

Rick

Article: 155628
Subject: Re: seperate high speed rules for HDL?
From: langwadt@fonz.dk
Date: Tue, 30 Jul 2013 16:25:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Tuesday, July 30, 2013 5:01:28 AM UTC+2, ske...@gmail.com wrote:
> Hi everyone. I'm trying to find out if, at high speeds, it is necessary t=
o clock every other register using every other clock transition. For instan=
ce, clocking every other register in a shift register using the positive cl=
ock transition and the rest use the negative clock transition. This VHDL ma=
y help explain:
>=20
>=20
>=20
> I know this works at lower speeds:
>=20
>=20
>=20
>    if(clk'event and clk=3D'1')then
>=20
>       D <=3D C;
>=20
>       C <=3D B;
>=20
>       B <=3D A;
>=20
>       A <=3D input;
>=20
>    end if;
>=20
>=20
>=20
> But I wonder if at higher speeds this sort of coding is required:
>=20
>=20
>=20
>    if(clk'event and clk=3D'1')then
>=20
>       D <=3D C;
>=20
>       B <=3D A;
>=20
>    end if
>=20
>    if(clk'event and clk=3D'0')then
>=20
>       C <=3D B;
>=20
>       A <=3D input;
>=20
>    end if;
>=20
>=20
>=20
> That way, in my second example, "B" for instance captures it's data in th=
e middle of "A's" data eye. Is this coding style required above some speed?=
 If so, does anyone know how to find out what that speed is or just tell me=
 some general approximate?


no you shouldn't do that it doesn't gain anything, if anything it'll make t=
hings slower.=20

in you example using both edges the output of A only has half as much time =
to get to input of B so it will only be able to run half as fast

FPGAs are generally designed so the clock arrives at all FFs at the same ti=
me
so all you need to check is if the path takes less time than a clock cycle =
minus setup time

and the hold time on FFs are zero or less so that paths can be arbitrarily =
fast

-Lasse







Article: 155629
Subject: Re: Lattice Announces EOL for XP and EC/P Product Lines
From: langwadt@fonz.dk
Date: Tue, 30 Jul 2013 16:44:21 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Wednesday, July 31, 2013 12:40:20 AM UTC+2, rickman wrote:
> On 7/30/2013 5:11 PM, Theo Markettos wrote:
> 
> > already5chosen@yahoo.com wrote:
> 
> >> If "nice" = 100 pin QFP, then yes, except for ancient Cyclone-I, Altera
> 
> >> does not have anything nice.
> 
> >>
> 
> >> But if 144 pin QFP is also o.k. then there are relatively modern Cyclone
> 
> >> III devices.  Voltage and the rest is more or less the same as Xilinx.
> 
> >
> 
> > There's some Cyclone IVs in 144ish QFP too.
> 
> 
> 
> I would love to use a 144 pin QFP, but they don't fit on the board.  It 
> 
> is a very narrow daughtercard, only 0.85" wide and the 144 QFP is 0.86" 
> 
> wide without counting the pad over hang.  A 17x17mm 256 BGA is the best 
> 
> of the rest so far.  It has a 1 mm pitch although I haven't looked at 
> 
> what it takes to get vias between the balls.  I expect I will need to be 
> 
> willing to push below the comfort zone of 6/6 mil space/trace and maybe 
> 
> below 10 mil drill.
> 

http://bmc.bu.edu/bmc/asd/tester/xapp157.pdf 

says 6/6 and 12mil drill is doable 


-Lasse


Article: 155630
Subject: Re: Lattice Announces EOL for XP and EC/P Product Lines
From: thomas.entner99@gmail.com
Date: Tue, 30 Jul 2013 16:59:50 -0700 (PDT)
Links: << >>  << T >>  << A >>

> In fact, I'm skipping Altera for the moment 

If you have some reasonable time that you can bridge with your LTB parts, I think you should really contact your local Altera FAE to see if he has some news for you.

Personally, I like Quartus the most by far when comparing it with the software from the other vendors (just look at SignalTap, for example). (I have no Vivado experience, however...)

Regards,

Thomas

www.entner-electronics.com

Article: 155631
Subject: Re: seperate high speed rules for HDL?
From: sketyro@gmail.com
Date: Tue, 30 Jul 2013 17:18:29 -0700 (PDT)
Links: << >>  << T >>  << A >>

> and the hold time on FFs are zero or less so that paths can be arbitrarily fast
>
> -Lasse

This I did not know. I feel like it should have come to me before now. Oh well. Thanks everyone!

Article: 155632
Subject: Re: Lattice Announces EOL for XP and EC/P Product Lines
From: Rob Doyle <radioengr@gmail.com>
Date: Tue, 30 Jul 2013 18:03:30 -0700
Links: << >>  << T >>  << A >>
On 7/30/2013 11:37 AM, rickman wrote:
> Spartan 6 parts give a *lot* more functionality, but I'd have to use
> a 256 pin 1.0 mm BGA *and* external flash *and* the 1.2 volt supply
> *and* they are twice the price.  Maybe I'll talk to the disties.
> Maybe they can do something about the price at least.

The smaller Spartan 6 parts do come in a 144 pin TQFP package. Too small?

Rob.

Article: 155633
Subject: Re: Lattice Announces EOL for XP and EC/P Product Lines
From: Jon Elson <elson@pico-systems.com>
Date: Tue, 30 Jul 2013 20:50:18 -0500
Links: << >>  << T >>  << A >>
rickman wrote:


> No S3AN in 100 pin QFP, this may be because it is a dual die
> configuration or more likely they just don't expect to sell a lot of
> this size.  I haven't bothered to check the price either.  They do have
> a FTG256 which might do the job.  I expect I can find the space for a
> very small 8 pin flash part if I go QFN.  Again, I need to dig more.
> I've just started looking...
> 
The smallest Spartan 3A is under $10, the 3AN is about $15.

> Actually my main concern with the external flash is the whole JTAG
> programming at the factory and/or lab thing, but there are likely many
> ways to deal with that including having them programmed before assembly.
>   It is just that I've been using these Flash FPGAs for some time now
> and I'm very used to them.
> 
The 3AN can be programmed by JTAG, the SST serial EPROM I use on
the 3A is not JTAG, although a flexible programmer or tester
could easily be "taught" the protocol.  I chose this device
so I could have field-replaceable firmware.  I had to make an
SO-8 to DIP converter board though, as the SST chip is only
available in a couple SMT packages.

Jon

Article: 155634
Subject: Re: Lattice Announces EOL for XP and EC/P Product Lines
From: Gabor <gabor@szakacs.org>
Date: Tue, 30 Jul 2013 22:25:03 -0400
Links: << >>  << T >>  << A >>
On 7/30/2013 9:03 PM, Rob Doyle wrote:
> On 7/30/2013 11:37 AM, rickman wrote:
>> Spartan 6 parts give a *lot* more functionality, but I'd have to use
>> a 256 pin 1.0 mm BGA *and* external flash *and* the 1.2 volt supply
>> *and* they are twice the price.  Maybe I'll talk to the disties.
>> Maybe they can do something about the price at least.
>
> The smaller Spartan 6 parts do come in a 144 pin TQFP package. Too small?
>
> Rob.

Apparently the 144 TQ package is too big (physically).  And once you
look at a 256-ball 1mm BGA you could find any number of devices
including those from Lattice (XP2?).  For internals, the smallest
Spartan 6 is about the size of the original XP part he was using.

As to price, we never pay anything near list for Xilinx parts, but
we don't get the same steep discount on Spartan 6 as we do on other
series.

-- 
Gabor

Article: 155635
Subject: Re: Lattice Announces EOL for XP and EC/P Product Lines
From: rickman <gnuarm@gmail.com>
Date: Wed, 31 Jul 2013 01:38:20 -0400
Links: << >>  << T >>  << A >>
On 7/30/2013 7:44 PM, langwadt@fonz.dk wrote:
> On Wednesday, July 31, 2013 12:40:20 AM UTC+2, rickman wrote:
>> On 7/30/2013 5:11 PM, Theo Markettos wrote:
>>
>>> already5chosen@yahoo.com wrote:
>>
>>>> If "nice" = 100 pin QFP, then yes, except for ancient Cyclone-I, Altera
>>
>>>> does not have anything nice.
>>
>>>>
>>
>>>> But if 144 pin QFP is also o.k. then there are relatively modern Cyclone
>>
>>>> III devices.  Voltage and the rest is more or less the same as Xilinx.
>>
>>>
>>
>>> There's some Cyclone IVs in 144ish QFP too.
>>
>>
>>
>> I would love to use a 144 pin QFP, but they don't fit on the board.  It
>>
>> is a very narrow daughtercard, only 0.85" wide and the 144 QFP is 0.86"
>>
>> wide without counting the pad over hang.  A 17x17mm 256 BGA is the best
>>
>> of the rest so far.  It has a 1 mm pitch although I haven't looked at
>>
>> what it takes to get vias between the balls.  I expect I will need to be
>>
>> willing to push below the comfort zone of 6/6 mil space/trace and maybe
>>
>> below 10 mil drill.
>>
>
> http://bmc.bu.edu/bmc/asd/tester/xapp157.pdf
>
> says 6/6 and 12mil drill is doable
>
>
> -Lasse

Thanks for the link, that saved me a little bother.  But I'll still need 
to run through the calcs myself.  A quick check says this works.  Still, 
I'm not crazy about using a 256 ball part when I only need 62 I/O... lol 
  Better than no choice at all.

-- 

Rick

Article: 155636
Subject: Re: Lattice Announces EOL for XP and EC/P Product Lines
From: rickman <gnuarm@gmail.com>
Date: Wed, 31 Jul 2013 01:52:30 -0400
Links: << >>  << T >>  << A >>
On 7/30/2013 9:50 PM, Jon Elson wrote:
> rickman wrote:
>
>
>> No S3AN in 100 pin QFP, this may be because it is a dual die
>> configuration or more likely they just don't expect to sell a lot of
>> this size.  I haven't bothered to check the price either.  They do have
>> a FTG256 which might do the job.  I expect I can find the space for a
>> very small 8 pin flash part if I go QFN.  Again, I need to dig more.
>> I've just started looking...
>>
> The smallest Spartan 3A is under $10, the 3AN is about $15.
>
>> Actually my main concern with the external flash is the whole JTAG
>> programming at the factory and/or lab thing, but there are likely many
>> ways to deal with that including having them programmed before assembly.
>>    It is just that I've been using these Flash FPGAs for some time now
>> and I'm very used to them.
>>
> The 3AN can be programmed by JTAG, the SST serial EPROM I use on
> the 3A is not JTAG, although a flexible programmer or tester
> could easily be "taught" the protocol.  I chose this device
> so I could have field-replaceable firmware.  I had to make an
> SO-8 to DIP converter board though, as the SST chip is only
> available in a couple SMT packages.

Yeah, I am supposed to provide JTAG programmability through the 
equipment this daughtercard is plugged into.  That is, I provide the 
JTAG port, it is up to them to do the software to program it.  That is 
one of my concerns with an external seral prom.  May not be easy to do 
in an 8 pin package... But if they can learn the protocol, maybe that 
would work too.  We'll see.  After 5 years we still have not required 
this functionality.  But I'll be pushing for increased capability in the 
new version to allow it to be sold into new areas.  So remote updates 
may be more important then.

-- 

Rick

Article: 155637
Subject: Re: Lattice Announces EOL for XP and EC/P Product Lines
From: rickman <gnuarm@gmail.com>
Date: Wed, 31 Jul 2013 01:58:17 -0400
Links: << >>  << T >>  << A >>
On 7/30/2013 10:25 PM, Gabor wrote:
> On 7/30/2013 9:03 PM, Rob Doyle wrote:
>> On 7/30/2013 11:37 AM, rickman wrote:
>>> Spartan 6 parts give a *lot* more functionality, but I'd have to use
>>> a 256 pin 1.0 mm BGA *and* external flash *and* the 1.2 volt supply
>>> *and* they are twice the price. Maybe I'll talk to the disties.
>>> Maybe they can do something about the price at least.
>>
>> The smaller Spartan 6 parts do come in a 144 pin TQFP package. Too small?
>>
>> Rob.
>
> Apparently the 144 TQ package is too big (physically). And once you
> look at a 256-ball 1mm BGA you could find any number of devices
> including those from Lattice (XP2?). For internals, the smallest
> Spartan 6 is about the size of the original XP part he was using.
>
> As to price, we never pay anything near list for Xilinx parts, but
> we don't get the same steep discount on Spartan 6 as we do on other
> series.

There is some irony, the parts the smallest Spartan 6 comes in are *too* 
small in terms of ball pitch.  They require PCB design rules down to 3/3 
trace/space.  To get a FTG256 BGA you have to bump up to the next size 
which is some four times bigger than the part I'm using now.  It has 
nearly 6K LUTs and they are 6 input LUTs rather than 4 input.  It also 
has tons of multipliers and RAM, so it is a *lot* more device.  The 
Digikey price is about double too..., but that can be negotiable.

-- 

Rick

Article: 155638
Subject: Re: Lattice Announces EOL for XP and EC/P Product Lines
From: rickman <gnuarm@gmail.com>
Date: Wed, 31 Jul 2013 02:00:57 -0400
Links: << >>  << T >>  << A >>
On 7/30/2013 2:37 PM, rickman wrote:
>
> I have yet to check out the Altera line. I don't remember them having
> anything I liked in a nice package. But that will be something to do
> later today. I guess I should check out the Micro-Semi line as well.
> It's been a while since I looked hard at their parts and, oh yeah, there
> is the PSOC from Cypress. I don't think that was an option at the time I
> did this design.

I went to the Cypress web site and I can't find a data sheet on their 
PSOC parts.  They also encrypt the info on the broad classes of devices 
behind marketing speak.  So I can't even get a feel for what they are 
capable of.

-- 

Rick

Article: 155639
Subject: Re: serial protocol specs and verification
From: alb <alessandro.basili@cern.ch>
Date: Wed, 31 Jul 2013 09:36:16 +0200
Links: << >>  << T >>  << A >>
On 29/07/2013 22:14, rickman wrote:
[]
>> Everyone's old favorite asynchronous serial RS232 usually uses a
>> clock at 16x, though I have seen 64x. From the beginning of the
>> start bit, it counts half a bit time (in clock cycles), verifies
>> the start bit (and not random noise) then counts whole bits and
>> decodes at that point. So, the actual decoding is done with a 1X
>> clock, but with 16 (or 64) possible phase values. It resynchronizes
>> at the beginning of each character, so it can't get too far off.
> 
> Yes, that protocol requires a clock matched to the senders clock to at
> least 2.5% IIRC.  The protocol the OP describes has much longer char
> sequences which implies much tighter clock precision at each end and I'm
> expecting it to use a clock recovery circuit... but maybe not.  I think
> he said they don't use one but get "frequent" errors.

At the physical level the bit stuffing will allow to resync continuously
therefore I'm not concerned if there's a clock recovery circuit.

We are using 40MHz (0.5 ppm stability) but after few seconds you can
already see how many cycles two clocks can drift apart.

> I've never analyzed an async design with longer data streams so I don't
> know how much precision would be required, but I"m sure you can't do
> reliable data recovery with a 2x clock (without a pll).  I think this
> would contradict the Nyquist criterion.

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

> In my earlier comments when I'm talking about a PLL I am referring to a
> digital PLL.  I guess I should have said a DPLL.

Why bothering? If you have a PLL on your FPGA you can profit of it,
otherwise you need something fancier.

Article: 155640
Subject: Re: serial protocol specs and verification
From: alb <alessandro.basili@cern.ch>
Date: Wed, 31 Jul 2013 11:11:34 +0200
Links: << >>  << T >>  << A >>
On 30/07/2013 06:45, Richard Damon wrote:
[]
>> Uhm, since there's a sync pattern of '111' I have to assume that no
>> frame is transmitted when only zeros are flowing (with the '1' stuffed
>> every 6 zeros).
> 
> My assumption for the protocol would be that between frames an "all
> zero" pattern is sent. (note that this is on the layer above the raw
> transport level, where every time 6 zeros are sent, a 1 is added). Thus
> all frames will begin with three 1s in a row, as a signal for start of
> frame (and also gives a lot of transitions to help lock the clock if
> using a pll).

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.

[]
>> I'm thinking about having a system clock multiplied internally via PLL
>> and then go for a x4 or x8 in order to center the bit properly.
> 
> I would think that sampling at 4x of the data rate is an minimum, faster
> will give you better margins for frequency errors. So with a 20 MHz data
> rate, you need to sample the data at 80 MHz, faster can help, and will
> cause less jitter in your recovered data clock out.

I also agree with you, no way a 2x would be sufficient to recover a
phase shift.

> 
> Note that the first level of processing will perform data detection and
> clock recovery, and this might be where the 40 MHz came from, a 40 MHz
> processing system can be told most of the time to take data every other
> clock cycle, but have bandwidth to at times if the data is coming in
> slightly faster to take data on two consecutive clocks. 

A 40 MHz would be sampling 2x, which is clearly not sufficient.

> You don't want
> to make this clock much faster than that, as then it becomes harder to
> design for no benefit. Any higher speed bit detection clock needs to
> have the results translated to this domain for further processing.  (You
> could also generate a recovered clock, but that starts you down the road
> to an async design as the recovered clock isn't well related to your
> existing clock, being a combinatorial result of registers clocked on
> your sampling clock.)

The deframed data (the data portion of the above mentioned frame
structure) are going into a fifo, I think I can rework it to be a dual
clock fifo to cross domain.

Article: 155641
Subject: Re: serial protocol specs and verification
From: rickman <gnuarm@gmail.com>
Date: Wed, 31 Jul 2013 07:44:17 -0400
Links: << >>  << T >>  << A >>
On 7/31/2013 3:36 AM, alb wrote:
> On 29/07/2013 22:14, rickman wrote:
> []
>>> Everyone's old favorite asynchronous serial RS232 usually uses a
>>> clock at 16x, though I have seen 64x. From the beginning of the
>>> start bit, it counts half a bit time (in clock cycles), verifies
>>> the start bit (and not random noise) then counts whole bits and
>>> decodes at that point. So, the actual decoding is done with a 1X
>>> clock, but with 16 (or 64) possible phase values. It resynchronizes
>>> at the beginning of each character, so it can't get too far off.
>>
>> Yes, that protocol requires a clock matched to the senders clock to at
>> least 2.5% IIRC.  The protocol the OP describes has much longer char
>> sequences which implies much tighter clock precision at each end and I'm
>> expecting it to use a clock recovery circuit... but maybe not.  I think
>> he said they don't use one but get "frequent" errors.
>
> At the physical level the bit stuffing will allow to resync continuously
> therefore I'm not concerned if there's a clock recovery circuit.
>
> We are using 40MHz (0.5 ppm stability) but after few seconds you can
> already see how many cycles two clocks can drift apart.
>
>> I've never analyzed an async design with longer data streams so I don't
>> know how much precision would be required, but I"m sure you can't do
>> reliable data recovery with a 2x clock (without a pll).  I think this
>> would contradict the Nyquist criterion.
>
> <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. 
Otherwise there wouldn't be so many errors in the existing circuit.


>> In my earlier comments when I'm talking about a PLL I am referring to a
>> digital PLL.  I guess I should have said a DPLL.
>
> Why bothering? If you have a PLL on your FPGA you can profit of it,
> otherwise you need something fancier.

Not sure of your context.  You can't use the PLL on the FPGA to recover 
the clock from an arbitrary data stream.  It is not designed for that 
and will not work because of the gaps in data transitions.  It is 
designed to allow the multiplication of clock frequencies.  A DPLL can 
be easily designed to recover the clock, but needs to be greater than 3x 
the data rate in order to distinguish the fast condition from the slow 
condition.

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

-- 

Rick

Article: 155642
Subject: Re: seperate high speed rules for HDL?
From: jonesandy@comcast.net
Date: Wed, 31 Jul 2013 05:39:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Tuesday, July 30, 2013 6:25:03 PM UTC-5, lang...@fonz.dk wrote:
> and the hold time on FFs are zero or less so that paths can be=20
> arbitrarily fast=20

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".

As to the original problem that the alternate-edge clocking scheme is presu=
mably trying to solve, there is a one-clock-cycle delay between A & C. But =
there are 2 t_setup and 2 t_clk2out times, since you are using an additiona=
l register on the opposite clock edge between A and C. You would be better =
off to perform the operations for B and C combinatorially in series between=
 A & C, without trying to use a register for B in between them.

Andy

Article: 155643
Subject: Re: serial protocol specs and verification
From: "RCIngham" <2161@embeddedrelated>
Date: Wed, 31 Jul 2013 08:36:54 -0500
Links: << >>  << T >>  << A >>
[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. 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.
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 155644
Subject: Re: seperate high speed rules for HDL?
From: langwadt@fonz.dk
Date: Wed, 31 Jul 2013 11:26:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Wednesday, July 31, 2013 2:39:03 PM UTC+2, jone...@comcast.net wrote:
> On Tuesday, July 30, 2013 6:25:03 PM UTC-5, lang...@fonz.dk wrote:
> 
> > and the hold time on FFs are zero or less so that paths can be 
> 
> > arbitrarily fast 
> 
> 
> 
> 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?

and if you can't assume the the skew is effectively zero how are you going to do a synchronous design?  

-Lasse

Article: 155645
Subject: Re: serial protocol specs and verification
From: langwadt@fonz.dk
Date: Wed, 31 Jul 2013 11:30:14 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Wednesday, July 31, 2013 1:44:17 PM UTC+2, rickman wrote:
> On 7/31/2013 3:36 AM, alb wrote:
> 
> > On 29/07/2013 22:14, rickman wrote:
> 
> > []
> 
> >>> Everyone's old favorite asynchronous serial RS232 usually uses a
> 
> >>> clock at 16x, though I have seen 64x. From the beginning of the
> 
> >>> start bit, it counts half a bit time (in clock cycles), verifies
> 
> >>> the start bit (and not random noise) then counts whole bits and
> 
> >>> decodes at that point. So, the actual decoding is done with a 1X
> 
> >>> clock, but with 16 (or 64) possible phase values. It resynchronizes
> 
> >>> at the beginning of each character, so it can't get too far off.
> 
> >>
> 
> >> Yes, that protocol requires a clock matched to the senders clock to at
> 
> >> least 2.5% IIRC.  The protocol the OP describes has much longer char
> 
> >> sequences which implies much tighter clock precision at each end and I'm
> 
> >> expecting it to use a clock recovery circuit... but maybe not.  I think
> 
> >> he said they don't use one but get "frequent" errors.
> 
> >
> 
> > At the physical level the bit stuffing will allow to resync continuously
> 
> > therefore I'm not concerned if there's a clock recovery circuit.
> 
> >
> 
> > We are using 40MHz (0.5 ppm stability) but after few seconds you can
> 
> > already see how many cycles two clocks can drift apart.
> 
> >
> 
> >> I've never analyzed an async design with longer data streams so I don't
> 
> >> know how much precision would be required, but I"m sure you can't do
> 
> >> reliable data recovery with a 2x clock (without a pll).  I think this
> 
> >> would contradict the Nyquist criterion.
> 
> >
> 
> > <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. 
> 
> Otherwise there wouldn't be so many errors in the existing circuit.
> 
> 
> 
> 
> 
> >> In my earlier comments when I'm talking about a PLL I am referring to a
> 
> >> digital PLL.  I guess I should have said a DPLL.
> 
> >
> 
> > Why bothering? If you have a PLL on your FPGA you can profit of it,
> 
> > otherwise you need something fancier.
> 
> 
> 
> Not sure of your context.  You can't use the PLL on the FPGA to recover 
> 
> the clock from an arbitrary data stream.  It is not designed for that 
> 
> and will not work because of the gaps in data transitions.  It is 
> 
> designed to allow the multiplication of clock frequencies.  A DPLL can 
> 
> be easily designed to recover the clock, but needs to be greater than 3x 
> 
> the data rate in order to distinguish the fast condition from the slow 
> 
> condition.
> 
> 
> 
> You can use the FPGA PLL to multiply your clock from 2x to 4x to allow 
> 
> the DPLL to work correctly.
> 

or do like many USB PHYs, assume the 2x clock in reasonably 50/50 and use
a DDR input flop to sample at 4x

-Lasse


Article: 155646
Subject: Re: seperate high speed rules for HDL?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 31 Jul 2013 19:22:53 +0000 (UTC)
Links: << >>  << T >>  << A >>
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

Article: 155647
Subject: Re: seperate high speed rules for HDL?
From: langwadt@fonz.dk
Date: Wed, 31 Jul 2013 13:59:49 -0700 (PDT)
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

Article: 155648
Subject: Re: Lattice Announces EOL for XP and EC/P Product Lines
From: GaborSzakacs <gabor@alacron.com>
Date: Wed, 31 Jul 2013 17:13:27 -0400
Links: << >>  << T >>  << A >>
rickman wrote:
> On 7/30/2013 9:50 PM, Jon Elson wrote:
>> rickman wrote:
>>
>>>
>> The smallest Spartan 3A is under $10, the 3AN is about $15.
>>
>>> Actually my main concern with the external flash is the whole JTAG
>>> programming at the factory and/or lab thing, but there are likely many
>>> ways to deal with that including having them programmed before assembly.
>>>    It is just that I've been using these Flash FPGAs for some time now
>>> and I'm very used to them.
>>>
>> The 3AN can be programmed by JTAG, the SST serial EPROM I use on
>> the 3A is not JTAG, although a flexible programmer or tester
>> could easily be "taught" the protocol.  I chose this device
>> so I could have field-replaceable firmware.  I had to make an
>> SO-8 to DIP converter board though, as the SST chip is only
>> available in a couple SMT packages.
> 
> Yeah, I am supposed to provide JTAG programmability through the 
> equipment this daughtercard is plugged into.  That is, I provide the 
> JTAG port, it is up to them to do the software to program it.  That is 
> one of my concerns with an external seral prom.  May not be easy to do 
> in an 8 pin package... But if they can learn the protocol, maybe that 
> would work too.  We'll see.  After 5 years we still have not required 
> this functionality.  But I'll be pushing for increased capability in the 
> new version to allow it to be sold into new areas.  So remote updates 
> may be more important then.
> 

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).

-- 
Gabor

Article: 155649
Subject: Re: serial protocol specs and verification
From: rickman <gnuarm@gmail.com>
Date: Wed, 31 Jul 2013 17:28:41 -0400
Links: << >>  << T >>  << A >>
On 7/31/2013 2:30 PM, langwadt@fonz.dk wrote:
> On Wednesday, July 31, 2013 1:44:17 PM UTC+2, rickman wrote:
>>
>> You can use the FPGA PLL to multiply your clock from 2x to 4x to allow
>> the DPLL to work correctly.
>>
>
> or do like many USB PHYs, assume the 2x clock in reasonably 50/50 and use
> a DDR input flop to sample at 4x

Yes, that would be interesting to design actually, the logic gets two 
bits at the same time rather than one bit, I guess it makes the machine 
a bit more complicated in that you have to deal with four states and 
four possible input combinations.  Still, not a big deal, just a bit of 
work on paper to understand the logic needed.

-- 

Rick



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