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 158375

Article: 158375
Subject: ERROR:MapLib:30 - LOC constraint P11 on vga_b_out<1> is invalid: No
From: Mike Field <mikefield1969@gmail.com>
Date: Sat, 24 Oct 2015 23:39:06 -0700 (PDT)
Links: << >>  << T >>  << A >>
Looks to me as if you have the wrong package set in your project settings.

Mike

Article: 158376
Subject: Re: DC Blocker
From: Mike Field <mikefield1969@gmail.com>
Date: Sun, 25 Oct 2015 00:07:09 -0700 (PDT)
Links: << >>  << T >>  << A >>
Not knowing your exact requirements, the simplest I can see would be a running average of a large number of samples, and subtract that.

E.g  total = total + sample(n) - sample(n-2048),  output = sample-total/2048.

The division would be a bit shift, and the 2k of samples could be held in a ram block.

It is pretty trivial to show that DC would be blocked, and signals at f/2048 will not be attenuated (as the average would be zero).

It would also be very fast and have minimal latency,  however it would introduce some phase distortion as it isn't symetrical.

If that is an issue for your application, then a way around it would be to total over 2047 samples, and subtract the total from 2047*sample(n-1024), then divide by 2048 (once again this can be implemented with addition, subtraction and bitshifts).
The output will be slightly attenuated (by 1/2048), but no phase distortion would occur. It will also have a latency of 1024 cycles or so.

Mike









Article: 158377
Subject: Re: ML405 Xilinx ISE 14.7
From: abirov@gmail.com
Date: Sun, 25 Oct 2015 00:09:07 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sunday, October 25, 2015 at 11:41:15 AM UTC+6, glen herrmannsfeldt wrote:
> abirov@gmail.com wrote:
> > Dear all first of all want thanx to everyone who belong to this 
> > forum and give help to each other.
>  
> > I checked ML405's schematic that pins, and are exist,
> > i used advice of Aurelian Lazarut (cleaning project files) 
> > but no success. It cannot be mapped.
>  
> > Could someone help me with this problem?
>  
> > Here is Errors.
>  
> > ERROR:MapLib:30 - LOC constraint M19 on SW1 is invalid: No such site on the
> >   device. To bypass this error set the environment variable 'XIL_MAP_LOCWARN'.
> 
> (snip of more similar messages)
> 
> My guess is that you have the wrong package set, and the pins are
> numbered different than the right package. 
> 
> -- glen

Only one package available FF672xxxxxxx

Article: 158378
Subject: Re: ERROR:MapLib:30 - LOC constraint P11 on vga_b_out<1> is invalid:
From: abirov@gmail.com
Date: Sun, 25 Oct 2015 00:25:11 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sunday, October 25, 2015 at 12:39:11 PM UTC+6, Mike Field wrote:
> Looks to me as if you have the wrong package set in your project settings.
> 
> Mike

There is only one package FF672 in design properties no any other, so i used it.

here is my UCF file :

NET "SW1" LOC = "M19" ;
NET "SW2" LOC = "P16" ;
NET "SW3" LOC = "M11" ;
NET "SW4" LOC = "N11" ;
NET "SW5" LOC = "M10" ;
NET "SW6" LOC = "M9" ;
NET "SW7" LOC = "N8" ;
NET "SW8" LOC = "N7" ;
NET "SW1" CLOCK_DEDICATED_ROUTE = FALSE;
NET "SW2" CLOCK_DEDICATED_ROUTE = FALSE;
NET "SW3" CLOCK_DEDICATED_ROUTE = FALSE;
NET "SW4" CLOCK_DEDICATED_ROUTE = FALSE;
NET "SW5" CLOCK_DEDICATED_ROUTE = FALSE;
NET "SW6" CLOCK_DEDICATED_ROUTE = FALSE;
NET "SW7" CLOCK_DEDICATED_ROUTE = FALSE;
NET "SW8" CLOCK_DEDICATED_ROUTE = FALSE;
NET "pushE"  LOC = "m6" ; 
NET "pushN"  LOC = "g11"  ; 
NET "pushS"  LOC = "l10"  ; 
NET "pushW"  LOC = "k8"  ; 
####################### VGA ######################
NET "vga_b_out<0>"  LOC = "P10" ; 
NET "vga_b_out<1>"  LOC = "P11" ; 
NET "vga_b_out<2>"  LOC = "R8" ;
NET "vga_b_out<3>"  LOC = "f4"  ; 
NET "vga_b_out<4>"  LOC = "j4"  ; 
NET "vga_b_out<5>"  LOC = "g9"  ; 
NET "vga_b_out<6>"  LOC = "j5"  ; 
NET "vga_b_out<7>"  LOC = "h3"  ; 
#NET "vga_blank_n"   LOC = "M24"  ; 
NET "vga_clk_out"   LOC = "AC7"  ; 
NET "vga_g_out<0>"  LOC = "N9" ; 
NET "vga_g_out<1>"  LOC = "N6" ; 
NET "vga_g_out<2>"  LOC = "p6"  ; 
NET "vga_g_out<3>"  LOC = "j3"  ; 
NET "vga_g_out<4>"  LOC = "k7"  ; 
NET "vga_g_out<5>"  LOC = "k3"  ; 
NET "vga_g_out<6>"  LOC = "g10"  ; 
NET "vga_g_out<7>"  LOC = "k6"  ; 
NET "VGA_HSYNC"  	  LOC = "C3"  ; 
#NET "vga_psave_n"   LOC = "M25"  ; 
NET "vga_r_out<0>"  LOC = "R6" ; 
NET "vga_r_out<1>"  LOC = "R7" ; 
NET "vga_r_out<2>"  LOC = "P9" ; 
NET "vga_r_out<3>"  LOC = "f3"  ; 
NET "vga_r_out<4>"  LOC = "h7"  ; 
NET "vga_r_out<5>"  LOC = "e3"  ; 
NET "vga_r_out<6>"  LOC = "g5"  ; 
NET "vga_r_out<7>"  LOC = "g10"  ; 
#NET "vga_sync_n"    LOC = "L23"  ; 
NET "VGA_VSYNC"  	  LOC = "d4"  ; 
########### CAMERA ###########
NET "camRST_i"      LOC = "w23";# | CLOCK_DEDICATED_ROUTE = FALSE; #36
NET "camFRAMEVALID" LOC = "v24";# | CLOCK_DEDICATED_ROUTE = FALSE; #38
NET "camLINEVALID"  LOC = "y23";# | CLOCK_DEDICATED_ROUTE = FALSE; #40
NET "camPIXCLK"     LOC = "ad20" |CLOCK_DEDICATED_ROUTE = FALSE; #42
NET "camDATA<4>"    LOC = "ad21" ;# | CLOCK_DEDICATED_ROUTE = FALSE; #44
NET "camDATA<5>"    LOC = "ac21" ;# | CLOCK_DEDICATED_ROUTE = FALSE; #46
NET "camDATA<6>"    LOC = "ad19" ;# | CLOCK_DEDICATED_ROUTE = FALSE; #48
NET "camDATA<7>"    LOC = "y17";# | CLOCK_DEDICATED_ROUTE = FALSE; #50
NET "camDATA<8>"    LOC = "ad18";# | CLOCK_DEDICATED_ROUTE = FALSE; #52
NET "camDATA<9>"    LOC = "aa17" ;# | CLOCK_DEDICATED_ROUTE = FALSE; #54
NET "camDATA<10>"   LOC = "ac17" ;# | CLOCK_DEDICATED_ROUTE = FALSE; #56
NET "camDATA<11>"   LOC = "ab17";# | CLOCK_DEDICATED_ROUTE = FALSE; #58
NET "camEXPOSURE"   LOC = "ab16";# | CLOCK_DEDICATED_ROUTE = FALSE; #60
NET "camOE"    	  LOC = "ab15";# | CLOCK_DEDICATED_ROUTE = FALSE; #62
NET "camCLKIN"      LOC = "aa15";# | CLOCK_DEDICATED_ROUTE = FALSE; #64
NET "camDATA<4>" IOSTANDARD = "LVCMOS33";
NET "camDATA<5>" IOSTANDARD = "LVCMOS33";
NET "camDATA<6>" IOSTANDARD = "LVCMOS33";
NET "camDATA<7>" IOSTANDARD = "LVCMOS33";
NET "camDATA<8>" IOSTANDARD = "LVCMOS33";
NET "camDATA<9>" IOSTANDARD = "LVCMOS33";
NET "camDATA<10>" IOSTANDARD = "LVCMOS33";
NET "camDATA<11>" IOSTANDARD = "LVCMOS33";
NET "camEXPOSURE" IOSTANDARD = "LVCMOS33";
NET "camFRAMEVALID" IOSTANDARD = "LVCMOS33";
NET "camLINEVALID" IOSTANDARD = "LVCMOS33";
NET "camRST_i"       IOSTANDARD = "LVCMOS33";
NET "camOE" IOSTANDARD = "LVCMOS33";
NET "camPIXCLK" IOSTANDARD = "LVCMOS33";
NET "camCLKIN" IOSTANDARD = "LVCMOS33";



Article: 158379
Subject: Re: ML405 Xilinx ISE 14.7
From: abirov@gmail.com
Date: Sun, 25 Oct 2015 00:30:16 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sunday, October 25, 2015 at 11:41:15 AM UTC+6, glen herrmannsfeldt wrote:
> abirov@gmail.com wrote:
> > Dear all first of all want thanx to everyone who belong to this 
> > forum and give help to each other.
>  
> > I checked ML405's schematic that pins, and are exist,
> > i used advice of Aurelian Lazarut (cleaning project files) 
> > but no success. It cannot be mapped.
>  
> > Could someone help me with this problem?
>  
> > Here is Errors.
>  
> > ERROR:MapLib:30 - LOC constraint M19 on SW1 is invalid: No such site on the
> >   device. To bypass this error set the environment variable 'XIL_MAP_LOCWARN'.
> 
> (snip of more similar messages)
> 
> My guess is that you have the wrong package set, and the pins are
> numbered different than the right package. 
> 
> -- glen

I created two topics one is this and second with more messages in https://groups.google.com/forum/#!topic/comp.arch.fpga/wu1bXFMvW7I please look at it. thanx for advance

Article: 158380
Subject: Re: ERROR:MapLib:30 - LOC constraint P11 on vga_b_out<1> is invalid:
From: abirov@gmail.com
Date: Sun, 25 Oct 2015 02:05:04 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sunday, October 25, 2015 at 1:25:15 PM UTC+6, abi...@gmail.com wrote:
> On Sunday, October 25, 2015 at 12:39:11 PM UTC+6, Mike Field wrote:
> > Looks to me as if you have the wrong package set in your project settings.
> > 
> > Mike
> 
> There is only one package FF672 in design properties no any other, so i used it.
> 
> here is my UCF file :
> 
> NET "SW1" LOC = "M19" ;
> NET "SW2" LOC = "P16" ;
> NET "SW3" LOC = "M11" ;

Partially solved. used link http://www.edaboard.com/thread11331.html

But appear next error :

ERROR:Pack:2811 - Directed packing was unable to obey the user design
   constraints (LOC=G10) which requires the combination of the symbols listed
   below to be packed into a single IOB component.

Article: 158381
Subject: Re: ERROR:MapLib:30 - LOC constraint P11 on vga_b_out<1> is invalid:
From: abirov@gmail.com
Date: Sun, 25 Oct 2015 02:10:25 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sunday, October 25, 2015 at 3:05:09 PM UTC+6, abi...@gmail.com wrote:
> On Sunday, October 25, 2015 at 1:25:15 PM UTC+6, abi...@gmail.com wrote:
> > On Sunday, October 25, 2015 at 12:39:11 PM UTC+6, Mike Field wrote:
> > > Looks to me as if you have the wrong package set in your project settings.
> > > 
> > > Mike
> > 
> > There is only one package FF672 in design properties no any other, so i used it.
> > 
> > here is my UCF file :
> > 
> > NET "SW1" LOC = "M19" ;
> > NET "SW2" LOC = "P16" ;
> > NET "SW3" LOC = "M11" ;
> 
> Partially solved. used link http://www.edaboard.com/thread11331.html
> 
> But appear next error :
> 
> ERROR:Pack:2811 - Directed packing was unable to obey the user design
>    constraints (LOC=G10) which requires the combination of the symbols listed
>    below to be packed into a single IOB component.

Solved http://www.xilinx.com/support/answers/36343.html

Article: 158382
Subject: Re: recovery/removal timing
From: "kaz" <37480@FPGARelated>
Date: Sun, 25 Oct 2015 15:50:05 -0500
Links: << >>  << T >>  << A >>


>>I've got trouble thinking how the GSR could be used for any useful
>thing
>by the designer.  The trouble with the GSR is that it's 
>>removal edge is slow, and asynchronous to everything.  So flops may
>>reset fine with this signal, but coming out of reset, the state's
>>still unknown.  The parts of a design that can make reliable use of
>>this, is a rare exception,not the rule, IMHO.
>>
>

True. Altera (possibly others) do not guarantee powerup state. GSR can
work in principle but vendors cannot guarantee how first edge of user
clock is going to be relative to GSR release. So internally generated
reset wouldn't work either as it will depend on powerup states. They
always advise of having external reliable reset source.

Kaz 


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

Article: 158383
Subject: Re: Found: an FPGA with internal tri-states
From: Jon Elson <elson@pico-systems.com>
Date: Sun, 25 Oct 2015 20:04:50 -0500
Links: << >>  << T >>  << A >>
Gabor Szakacs wrote:


> 
> If you want another old FPGA with internal tristate that is still in
> production, check out Xilinx Spartan 2.  It's also 5V tolerant...
> 
These were officially discontinued some years back, but some big customers 
must have squealed VERY loudly!  Digi-key even has stock of straight Spartan 
2, but no stock or prices on Spartan 2E, which I did use in a product.
I've moved on the Spartan 3A, which works nicely, and as long as they keep 
making those, they are a VERY good price for an FPGA.

Spartan 2 and 2E have not been supported by their tools in a long time.  I 
think Ise 10.1 is the last to support them.  Fortunately, Xilinx does make 
their legacy tools available!

Jon

Article: 158384
Subject: Re: Question about partial multiplication result in transposed FIR
From: David Brown <david.brown@hesbynett.no>
Date: Mon, 26 Oct 2015 09:31:50 +0100
Links: << >>  << T >>  << A >>
On 23/10/15 20:55, Kevin Neilson wrote:
> David, I like your explanation of mapping the field elements to
> something abstract, like 0, 1, a, b, c, d, e, f.  I've only seen one
> textbook that mentioned something like this (it used Greek letters)
> and I found it very helpful to realize that the field elements are
> only arbitrarily *mapped* to integers and are not equivalent to
> them.

For non-algebraists, the use of numbers and "addition" and
"multiplication" in field theory can be very confusing - "normal" people
are too used to identities such as "two times x equals x plus x" that
have no equivalent in fields such as GF(2^n).  Using letters or other
symbols helps make things clear.

> 
> I don't use ROMs for field multiplication.  A GF(2048) multiplier
> takes about 64 6-input LUTs, as I recall, with about 3 levels of
> logic.  A fixed multiplier (multiplying by a constant) is more like
> 20 LUTs.  I use ROMs for division (find the reciprocal), cubing, etc.
> If you use ROMs for multiplication it induces a lot of latency,
> because you have 2-3 cycles for each blockRAM, and you have to do a
> log and antilog lookup, so you can end up with 5+ cycles of latency. 
> Kevin
> 

There's always a balance between throughput, latency and resource usage,
depending on your requirements.  My experience with these is in software
rather than FPGA, where the balances are a little different.




Article: 158385
Subject: Re: Found: an FPGA with internal tri-states
From: GaborSzakacs <gabor@alacron.com>
Date: Mon, 26 Oct 2015 09:43:43 -0400
Links: << >>  << T >>  << A >>
Jon Elson wrote:
> Gabor Szakacs wrote:
> 
> 
>> If you want another old FPGA with internal tristate that is still in
>> production, check out Xilinx Spartan 2.  It's also 5V tolerant...
>>
> These were officially discontinued some years back, but some big customers 
> must have squealed VERY loudly!  Digi-key even has stock of straight Spartan 
> 2, but no stock or prices on Spartan 2E, which I did use in a product.
> I've moved on the Spartan 3A, which works nicely, and as long as they keep 
> making those, they are a VERY good price for an FPGA.
> 
> Spartan 2 and 2E have not been supported by their tools in a long time.  I 
> think Ise 10.1 is the last to support them.  Fortunately, Xilinx does make 
> their legacy tools available!
> 
> Jon

EOL was announced for Spartan-2 some years back and then it was
retracted.  Spartan 2E is no longer manufactured.  My guess is that it
was easier to migrate from 2E to newer parts since 2E was already not
5V tolerant.  In any case, Xilinx is generally happy to continue to
supply old parts as long as there is enough demand and as long as the
fab partners still have the process used to build the parts.  Xilinx
has never migrated an existing part to a different process node, and
probably never will.

-- 
Gabor

Article: 158386
Subject: Re: Question about partial multiplication result in transposed FIR filter
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Mon, 26 Oct 2015 09:06:27 -0700 (PDT)
Links: << >>  << T >>  << A >>

>=20
> For non-algebraists, the use of numbers and "addition" and
> "multiplication" in field theory can be very confusing - "normal" people
> are too used to identities such as "two times x equals x plus x" that
> have no equivalent in fields such as GF(2^n).  Using letters or other
> symbols helps make things clear.
>=20
It *is* confusing.  If x is an element of a field, then (x+1)^2 =3D x^2+2x+=
1, but the '2' in '2x' isn't the '2' from the field (i.e., alpha^1); it's t=
he regular integer 2.  This was confusing to me initially.  It just makes m=
ore sense to write 'x+x' instead of '2x' (which is 0, of course, if the fie=
ld is Gf(2^n)).

Article: 158387
Subject: Re: Found: an FPGA with internal tri-states
From: Jon Elson <elson@pico-systems.com>
Date: Mon, 26 Oct 2015 22:49:51 -0500
Links: << >>  << T >>  << A >>
GaborSzakacs wrote:

  Xilinx
> has never migrated an existing part to a different process node, and
> probably never will.
> 
The engineering of the LUTs is pretty difficult, and probably requires a 
number of prototypes to get all the paths time-equalized so that under all 
cases the LUT is glitchless.  Also, getting the skew-free clock lines just 
right is probably difficult.  if they scaled the chip, the timing 
simulations would all be off.

So, it seems to me that scaling the chip would be essentially the same 
effort as designing a whole new chip from scratch.  I think this is where 
FPGAs are just a little bit different from typical logic parts.

Jon

Article: 158388
Subject: Re: Found: an FPGA with internal tri-states
From: rickman <gnuarm@gmail.com>
Date: Tue, 27 Oct 2015 03:18:57 -0400
Links: << >>  << T >>  << A >>
On 10/26/2015 11:49 PM, Jon Elson wrote:
> GaborSzakacs wrote:
>
>    Xilinx
>> has never migrated an existing part to a different process node, and
>> probably never will.
>>
> The engineering of the LUTs is pretty difficult, and probably requires a
> number of prototypes to get all the paths time-equalized so that under all
> cases the LUT is glitchless.  Also, getting the skew-free clock lines just
> right is probably difficult.  if they scaled the chip, the timing
> simulations would all be off.

I've never heard anyone say LUTs are glitch free because they are timing 
controlled.  They are glitchless because they use pass transistor 
switches rather than gates for the mux.  But I can't say I am 
knowledgeable about this.  I just recall the description by the Xilinx 
guys who used to post here and they didn't talk about balancing timing 
in the LUTs.


> So, it seems to me that scaling the chip would be essentially the same
> effort as designing a whole new chip from scratch.  I think this is where
> FPGAs are just a little bit different from typical logic parts.

I won't argue that this isn't true for the newer generations.  I don't 
know it is for the same reasons.

-- 

Rick

Article: 158389
Subject: Re: Found: an FPGA with internal tri-states
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 27 Oct 2015 18:17:38 +0000 (UTC)
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:
> On 10/26/2015 11:49 PM, Jon Elson wrote:

(snip)
>> The engineering of the LUTs is pretty difficult, and probably requires a
>> number of prototypes to get all the paths time-equalized so that under all
>> cases the LUT is glitchless.  Also, getting the skew-free clock lines just
>> right is probably difficult.  if they scaled the chip, the timing
>> simulations would all be off.
 
> I've never heard anyone say LUTs are glitch free because they are timing 
> controlled.  They are glitchless because they use pass transistor 
> switches rather than gates for the mux.  But I can't say I am 
> knowledgeable about this.  I just recall the description by the Xilinx 
> guys who used to post here and they didn't talk about balancing timing 
> in the LUTs.

Yes, but you have to time the pass transistors right.

Well, mostly you have to be sure not to go into any other state
on the way to the right one. 
 
>> So, it seems to me that scaling the chip would be essentially the same
>> effort as designing a whole new chip from scratch.  I think this is where
>> FPGAs are just a little bit different from typical logic parts.
 
> I won't argue that this isn't true for the newer generations.  
> I don't know it is for the same reasons.

Seems to me that retiming an existing design has to be easier than
completely designing a new one, but maybe not all that much easier.

-- glen


Article: 158390
Subject: Re: Found: an FPGA with internal tri-states
From: rickman <gnuarm@gmail.com>
Date: Tue, 27 Oct 2015 15:50:00 -0400
Links: << >>  << T >>  << A >>
On 10/27/2015 2:17 PM, glen herrmannsfeldt wrote:
> rickman <gnuarm@gmail.com> wrote:
>> On 10/26/2015 11:49 PM, Jon Elson wrote:
>
> (snip)
>>> The engineering of the LUTs is pretty difficult, and probably requires a
>>> number of prototypes to get all the paths time-equalized so that under all
>>> cases the LUT is glitchless.  Also, getting the skew-free clock lines just
>>> right is probably difficult.  if they scaled the chip, the timing
>>> simulations would all be off.
>
>> I've never heard anyone say LUTs are glitch free because they are timing
>> controlled.  They are glitchless because they use pass transistor
>> switches rather than gates for the mux.  But I can't say I am
>> knowledgeable about this.  I just recall the description by the Xilinx
>> guys who used to post here and they didn't talk about balancing timing
>> in the LUTs.
>
> Yes, but you have to time the pass transistors right.
>
> Well, mostly you have to be sure not to go into any other state
> on the way to the right one.

I believe this only requires that the switching time for on time is 
longer than the off time.  Then none of the pass transistors short 
different value memory cells together and invalid states and glitches 
are prevented, just a smooth transition between states.


>>> So, it seems to me that scaling the chip would be essentially the same
>>> effort as designing a whole new chip from scratch.  I think this is where
>>> FPGAs are just a little bit different from typical logic parts.
>
>> I won't argue that this isn't true for the newer generations.
>> I don't know it is for the same reasons.
>
> Seems to me that retiming an existing design has to be easier than
> completely designing a new one, but maybe not all that much easier.

I believe there is a *lot* of footwork that goes into designing the 
logic cells for a new process if you want optimum results.  That is 
where the work is and where the risk of respin is.  The logical 
structure is fairly cut and dried.  Porting a logic cell design to a new 
process should be a lot less work if you are not trying to optimize it. 
  The question is, why would anyone want to port an older generation 
FPGA architecture to a new process when they are already designing a new 
family?  The only reason would be to save customers the trouble of 
porting their designs to the new family.  This would also require 
compatible pin outs which seem to be anathema in the FPGA world unlike 
the MCU world where they try very hard to share as much commonality in 
pinouts as possible.

I would really like to see an MCU maker come out with FPGA enabled 
products.  I know the bulk of the work would be in ramping up the FPGA 
side development software.  Patents would not be a serious issue as most 
of the basic ones have run out.  A low end FPGA/CPU design wouldn't need 
to be state of the art as most designs don't push the envelope for 
FPGAs.  Mostly designers just want something that works.

Cypress has some devices with "configurable" logic blocks, but they are 
more like programmable I/O devices than they are generic logic and very 
limited.

-- 

Rick

Article: 158391
Subject: Re: recovery/removal timing
From: psustew <googleforums@digitaldesignconcepts.org>
Date: Thu, 29 Oct 2015 00:40:48 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Friday, October 9, 2015 at 4:25:25 PM UTC-4, zak wrote:
> Hi All,
>=20
> In Altera devices (at least) it is recommended that reset be applied to
> the async port of flips. It is also recommended that such reset should be
> pre-synchronised before wiring it to these async ports. This saves
> resource and helps recovery/removal timing.=20
>=20
> What exactly is recovery/removal. I know it is defined in terms of reset
> release and that reset should not be de-asserted close to clock edge. Fai=
r
> enough but is this independent of D input? I mean if D input is stable (o=
r
> passes setup/hold) does it matter still that reset release near clock edg=
e
> will be problem on its own. From timieQuest it looks certainly that it
> does matter but why? How is reset actually applied inside the flip?
>=20
> Any help appreciated.
>=20
> Zak
> =20
> ---------------------------------------
> Posted through http://www.FPGARelated.com

One of fundamental aspects of implementing an asynchronous reset, which is =
often overlooked, is that the reset must be DEASSERTED with proper timing m=
argin with respect to the clock.  This is why Altera, and many other vendor=
s recommend synching the reset to the relevant clock domain.  Recovery is d=
efined as the setup time of the deassertion of the reset with respect to th=
e clock.  Removal is defined as the hold time of the deassertion of the res=
et with respect to the clock.  This is defined in the Altera documenation -=
- I think it's in the Quartus handbook.    Timequest does an excellent job =
analyzing these paths if proper timing constraints are defined.

Robert - lead VHDL/Verilog trainer
www.digitaldesignconcepts.org

Article: 158392
Subject: Re: recovery/removal timing
From: "zak" <93737@FPGARelated>
Date: Thu, 29 Oct 2015 07:34:41 -0500
Links: << >>  << T >>  << A >>

>One of fundamental aspects of implementing an asynchronous reset, which
is
>often overlooked, is that the reset must be DEASSERTED with proper
timing
>margin with respect to the clock.  This is why Altera, and many other
>vendors recommend synching the reset to the relevant clock domain. 
Recovery is
>defined as the setup time of the deassertion of the reset with respect
to
>the clock.  Removal is defined as the hold time of the deassertion of
the
>reset with respect to the clock.  This is defined in the Altera
documenation
>-- I think it's in the Quartus handbook.    Timequest does an excellent
job
>analyzing these paths if proper timing constraints are defined.
>
>Robert - lead VHDL/Verilog trainer
>www.digitaldesignconcepts.org

Thanks Robert,

My original question was not about "standard" definitions of
recovery/removal but rather the relation of reset deassertion to D input.


Normally with setup/hold if D is not changing then timing violation does
not apply. 
Does this apply to recovery/removal as well with respect to D input?

I think Mark Curry answered my question. I will be grateful if you can
share your views with this regard.

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

Article: 158393
Subject: Re: recovery/removal timing
From: "jt_eaton" <84408@FPGARelated>
Date: Thu, 29 Oct 2015 10:04:15 -0500
Links: << >>  << T >>  << A >>

>
>Normally with setup/hold if D is not changing then timing violation 
>does not apply. 
>Does this apply to recovery/removal as well with respect to D input?
>


If your D input is 1 then the timing between reset deassert and clock will
determine whether the flop stays 0 or flips to 1.

If your D input is 0 then it shouldn't matter because you are choosing
between staying at 0 or loading a 0. Its the same result either way.

The problem is that this depends on how the flop is implemented. If you
build a flop using multiplexers and don't use glitchless muxes then it
would be possible to see a 1 in this situation.

Your silicon vendors data sheet should spell this out. If it is missing or
ambiguous then be afraid, be very afraid.

John Eaton



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

Article: 158394
Subject: Re: recovery/removal timing
From: KJ <kkjennings@sbcglobal.net>
Date: Thu, 29 Oct 2015 09:55:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Thursday, October 29, 2015 at 11:04:19 AM UTC-4, jt_eaton wrote:
> 
> 
> If your D input is 1 then the timing between reset deassert and clock will
> determine whether the flop stays 0 or flips to 1.
> 
> If your D input is 0 then it shouldn't matter because you are choosing
> between staying at 0 or loading a 0. Its the same result either way.
> 

If you violate timing you should not necessarily expect things to work properly so saying "...choosing between staying at 0 or loading a 0. Its the same result either way" on your second example is rolling the dice and hoping you won't get unlucky.

Kevin Jennings

Article: 158395
Subject: Re: recovery/removal timing
From: "zak" <93737@FPGARelated>
Date: Thu, 29 Oct 2015 12:38:45 -0500
Links: << >>  << T >>  << A >>
>On Thursday, October 29, 2015 at 11:04:19 AM UTC-4, jt_eaton wrote:
>> 
>> 
>> If your D input is 1 then the timing between reset deassert and clock
>will
>> determine whether the flop stays 0 or flips to 1.
>> 
>> If your D input is 0 then it shouldn't matter because you are choosing
>> between staying at 0 or loading a 0. Its the same result either way.
>> 
>
>If you violate timing you should not necessarily expect things to work
>properly so saying "...choosing between staying at 0 or loading a 0. Its
the
>same result either way" on your second example is rolling the dice and
>hoping you won't get unlucky.
>
>Kevin Jennings

Well in that case how do we explain that the well documented reset sync
design works.
I mean that design that connects reset to async port of two stages
synchroniser but connects D input of first register to '1'. If it is
matter of dice that design would not be reliable as claimed. (also known
as filtered reset design)

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

Article: 158396
Subject: Re: recovery/removal timing
From: KJ <kkjennings@sbcglobal.net>
Date: Thu, 29 Oct 2015 11:02:31 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Thursday, October 29, 2015 at 1:38:50 PM UTC-4, zak wrote:
> >On Thursday, October 29, 2015 at 11:04:19 AM UTC-4, jt_eaton wrote:
> >> 
> >> 
> >> If your D input is 1 then the timing between reset deassert and clock
> >will
> >> determine whether the flop stays 0 or flips to 1.
> >> 
> >> If your D input is 0 then it shouldn't matter because you are choosing
> >> between staying at 0 or loading a 0. Its the same result either way.
> >> 
> >
> >If you violate timing you should not necessarily expect things to work
> >properly so saying "...choosing between staying at 0 or loading a 0. Its
> the
> >same result either way" on your second example is rolling the dice and
> >hoping you won't get unlucky.
> >
> >Kevin Jennings
> 
> Well in that case how do we explain that the well documented reset sync
> design works.
> I mean that design that connects reset to async port of two stages
> synchroniser but connects D input of first register to '1'. If it is
> matter of dice that design would not be reliable as claimed. (also known
> as filtered reset design)
> 

Several reasons:
- If it really was so 'reliable' then you would only need one stage synchronizer, not two.  But you do need two or more in order to be reliable because you will likely be violating timing on each flip flop in that reset synchronizer.
- The resets you are talking about typically happen once per power up, not millions of times per second so the chances of you seeing it fail are slim
- If you get an *extra* errant reset clock cycle for some reason you wouldn't know it because the system wouldn't reset.  It's only if no reset gets generated that you *might* notice that things are not as they should be.
- Most flip flops in a design do not need to be reset with a global reset at all.  Those that don't have that need will be unaffected by whether or not there actually is a reset to that flip flop.

Kevin Jennings

Article: 158397
Subject: Re: recovery/removal timing
From: "zak" <93737@FPGARelated>
Date: Thu, 29 Oct 2015 13:21:39 -0500
Links: << >>  << T >>  << A >>

>
>Several reasons:
>- If it really was so 'reliable' then you would only need one stage
>synchronizer, not two.  But you do need two or more in order to be
reliable
>because you will likely be violating timing on each flip flop in that
reset
>synchronizer.
>Kevin Jennings

I think you are misunderstanding the filtered reset design. It connects
reset to async port of BOTH flops. So it is not worried about second flop
i.e. no problem will occur there if reset is released near its clock edge
and there is no third flop to put it right.

Moreover Altera says this design metsatbility proof (I assume 100%)

Zak 


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

Article: 158398
Subject: Re: recovery/removal timing
From: rickman <gnuarm@gmail.com>
Date: Thu, 29 Oct 2015 14:40:10 -0400
Links: << >>  << T >>  << A >>
On 10/29/2015 2:21 PM, zak wrote:
>>
>> Several reasons:
>> - If it really was so 'reliable' then you would only need one stage
>> synchronizer, not two.  But you do need two or more in order to be
> reliable
>> because you will likely be violating timing on each flip flop in that
> reset
>> synchronizer.
>> Kevin Jennings
>
> I think you are misunderstanding the filtered reset design. It connects
> reset to async port of BOTH flops. So it is not worried about second flop
> i.e. no problem will occur there if reset is released near its clock edge
> and there is no third flop to put it right.
>
> Moreover Altera says this design metsatbility proof (I assume 100%)

It has been demonstrated time and time again that there is no such thing 
as "metastability proof" in FFs.

This also can occur in mechanical devices and I just realized that the 
penultimate mechanical time piece is subject to this problem.  The 
Shortt double pendulum clock has a mechanism that speeds up the slave 
pendulum when needed based on the relative timing of the two pendulums. 
  The mechanism that detects this is subject to metastability or a 
similar effect.  When timed just "wrong", on the cusp of decision 
between fast and slow the mechanism misapplies the speed up mechanism 
giving a chaotic jolt to the slave pendulum (potentially the opposite of 
the intended direction).  I expect this perturbation has little 
consequence, but it is interesting that it happens.

The kicker on the master pendulum uses a gravity lever to give it a push 
every 30 swings.  This is timed by the slave pendulum, so there will 
still be small perturbations in the strength of the push, but nothing 
like metastability that I can see.

-- 

Rick

Article: 158399
Subject: Re: recovery/removal timing
From: KJ <kkjennings@sbcglobal.net>
Date: Thu, 29 Oct 2015 11:43:42 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Thursday, October 29, 2015 at 2:21:45 PM UTC-4, zak wrote:
>=20
> I think you are misunderstanding the filtered reset design.=20

Or perhaps you're misunderstanding it.  I'm assuming that you're referring =
to 'Synchronized Asynchronous Reset' in chapter 12 of the Quartus handbook =
(specifically, Figure 12-20) [1]...but who knows

>=20
> Moreover Altera says this design metsatbility proof (I assume 100%)
>=20

They made no such claim in this section.  Altera states no reason for havin=
g the second flip flop, but I would claim that it is there specifically for=
 metastability protection.  As with any metastability protection, that seco=
nd flip flop will not be a 100% guarantee, but it will be close enough to f=
or practical purposes.

You can assume whatever you want based on your incorrect recall of the circ=
uit.  That would be rolling the dice again.

Kevin Jennings

[1] https://www.altera.co.jp/ja_JP/pdfs/literature/hb/qts/qts_qii51006.pdf =
page 12-32



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