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 158350

Article: 158350
Subject: Re: DC Blocker
From: "Michael Kellett" <nospam@invalid.com>
Date: fri, 23 oct 2015 10:58:47 +0100
Links: << >>  << T >>  << A >>
b2508:
>>On 10/22/2015 4:50 PM, b2508 wrote:
>>>> In article <2Z-dnUTCaKvCqLTLnZ2dnUU7-VOdnZ2d@giganews.com>,
>>>> b2508 <108118@FPGARelated> wrote:
>>>>> Hm.. I tought that multiplication cannot be implemented without
> delay.
>>>>>
>>>>> This could cause timing issues to my knowledge.
>>>>>
>>>>> Moreover, full formula is
>>>>>
>>>>> y[n] = Q {x[n] - x[n-1] + p*y[n-1] - e[n-1]}
>>>>> e[n] = x[n] - x[n-1] + p*y[n-1] - e[n-1] - y[n]
>>>>>
>>>>> Error is difference between output before and after quantization.
>>>>> I asked for the initial one because even that i don't know how to
>>>>> implement.
>>>>>
>>>>> if x1 appears at t1, corresponding y1 is ready at earlies at
> t2=t1+1.
>>If
>>> I
>>>>> register subtracting operation as well, e1 is available at
t3=t1+1.
>>>>> However x2 arrives at t2 and neither y1 (corresponding y[n-1]) or
e1
>>> are
>>>>> ready at that time.
>>>>
>>>> Without really looking at your required function in detail (just
> noting
>>>> that it has feedback terms) - I'll just note in general.
>>>>
>>>> The statement "multiplication cannot be implemented without delay"
is
>>>> false, in many ways.  It all depends on your processing
requirements.
>>>> What is your sample rate?  What are your bit widths?
>>>>
>>>> You're processing clock does NOT need to be the same as your
sample
>>> clock.
>>>> If you wish them to be the same - it may be easier for new FPGA
users
> to
>>>
>>>> design - then you MAY be able to run the multiplier full
combinational
> -
>>>
>>>> If you're sample rate is low enough.
>>>>
>>>> The alternative (at a high level) is to buffer an input and
output,
> and
>>>> process with a faster processing clock.  Modern FPGA's these days
can
>>run
>>>
>>>> DSP functions upwards to around 400-500 MHz.  This is likely much
> faster
>>>
>>>> than your sample rate.
>>>>
>>>> Regards,
>>>> Mark
>>>
>>> OK, I was taught that it is always safer to put registers wherever
you
>>> can. I have no choice in my project but to have same sampling and
>>> processing rate.
>>>
>>> My rate is 100 MHz.
>>> Input data or x[n] has data format - unsigned, 16 bit, 1 bit for
> integer.
>>>
>>> Also, I am not sure how to select data widths after each of these
>>> operations.
>>>
>>> If x[n] and x[n-1] are 16/1 and their subtraction is 17 bit
unsigned
> with
>>> 2 bit integers, how do I proceed with data width selection?
Feedback
> loop
>>> part is unclear to me.
>>> Also, should I use DSP48 for the multiplication with P or should I
> make
>>it
>>> somehow power of two and do it by shifting?
>>>
>>> Q is quantization, or reducing number of samples after all these
>>> operations.
>>
>>Do you know the value of P?  Multiplies are done by shifting and
adding.
> 
>>  I don't know which chip you are planning to use, but all the
>>multipliers I know of require pipelining, the only option is how many
>>stages, 1, 2, etc...  Since P is a constant (it *is* a constant,
right?)
> 
>>you only need to use adders for the 1s, or if there are long runs of
1s
>>or 0s, you can subtract at the lsb of the run and add in at the bit
just
> 
>>past the msb of the run.  The point is you may not need to use a
built
>>in multiplier.
>>
>>Your filter seems very complex for a feedback filter.  Is there some
>>special need driving this?  Can you use a simpler filter?
>>
>>--
>>
>>Rick
> 
> I do not really know the value of P or how to determine it. I was
thinking
> to use 0.99 because I tried it out in software simulation and it seems
to
> do what I wanted it to do. The idea for this filter came from this
article
> / second filter on Figure 2.
> 
> http://www.digitalsignallabs.com/dcblock.pdf
> 
> Someone said to forget equations and do as it is drawn in figure, but
> these figures never account for potential latency of the
> add/subtract/multiply blocks or if I do not add registers, then I may
have
> timing issues.
> 
> Anyway, I will try to do add and multiply in one clock cycle and see
where
> this gets me. 
> 
> Thank you all very much anyhow.
> 
> 
> ---------------------------------------
> Posted through http://www.FPGARelated.com

Here's  a neat way to do it (if using Xilinx parts) and quite  alot of
helpful discussion:

www.xilinx.com/support/documentation/white_papers/wp279.pdf

MK

Article: 158351
Subject: Re: DC Blocker
From: Allan Herriman <allanherriman@hotmail.com>
Date: 23 Oct 2015 10:45:52 GMT
Links: << >>  << T >>  << A >>
On Fri, 23 Oct 2015 02:51:42 -0500, b2508 wrote:

>>On 10/22/2015 4:50 PM, b2508 wrote:
>>>> In article <2Z-dnUTCaKvCqLTLnZ2dnUU7-VOdnZ2d@giganews.com>,
>>>> b2508 <108118@FPGARelated> wrote:
>>>>> Hm.. I tought that multiplication cannot be implemented without
> delay.
>>>>>
>>>>> This could cause timing issues to my knowledge.
>>>>>
>>>>> Moreover, full formula is
>>>>>
>>>>> y[n] = Q {x[n] - x[n-1] + p*y[n-1] - e[n-1]}
>>>>> e[n] = x[n] - x[n-1] + p*y[n-1] - e[n-1] - y[n]
>>>>>
>>>>> Error is difference between output before and after quantization.
>>>>> I asked for the initial one because even that i don't know how to
>>>>> implement.
>>>>>
>>>>> if x1 appears at t1, corresponding y1 is ready at earlies at
> t2=t1+1.
>>If
>>> I
>>>>> register subtracting operation as well, e1 is available at t3=t1+1.
>>>>> However x2 arrives at t2 and neither y1 (corresponding y[n-1]) or e1
>>> are
>>>>> ready at that time.
>>>>
>>>> Without really looking at your required function in detail (just
> noting
>>>> that it has feedback terms) - I'll just note in general.
>>>>
>>>> The statement "multiplication cannot be implemented without delay" is
>>>> false, in many ways.  It all depends on your processing requirements.
>>>> What is your sample rate?  What are your bit widths?
>>>>
>>>> You're processing clock does NOT need to be the same as your sample
>>> clock.
>>>> If you wish them to be the same - it may be easier for new FPGA users
> to
>>>
>>>> design - then you MAY be able to run the multiplier full
>>>> combinational
> -
>>>
>>>> If you're sample rate is low enough.
>>>>
>>>> The alternative (at a high level) is to buffer an input and output,
> and
>>>> process with a faster processing clock.  Modern FPGA's these days can
>>run
>>>
>>>> DSP functions upwards to around 400-500 MHz.  This is likely much
> faster
>>>
>>>> than your sample rate.
>>>>
>>>> Regards,
>>>> Mark
>>>
>>> OK, I was taught that it is always safer to put registers wherever you
>>> can. I have no choice in my project but to have same sampling and
>>> processing rate.
>>>
>>> My rate is 100 MHz.
>>> Input data or x[n] has data format - unsigned, 16 bit, 1 bit for
> integer.
>>>
>>> Also, I am not sure how to select data widths after each of these
>>> operations.
>>>
>>> If x[n] and x[n-1] are 16/1 and their subtraction is 17 bit unsigned
> with
>>> 2 bit integers, how do I proceed with data width selection? Feedback
> loop
>>> part is unclear to me.
>>> Also, should I use DSP48 for the multiplication with P or should I
> make
>>it
>>> somehow power of two and do it by shifting?
>>>
>>> Q is quantization, or reducing number of samples after all these
>>> operations.
>>
>>Do you know the value of P?  Multiplies are done by shifting and adding.
> 
>>  I don't know which chip you are planning to use, but all the
>>multipliers I know of require pipelining, the only option is how many
>>stages, 1, 2, etc...  Since P is a constant (it *is* a constant, right?)
> 
>>you only need to use adders for the 1s, or if there are long runs of 1s
>>or 0s, you can subtract at the lsb of the run and add in at the bit just
> 
>>past the msb of the run.  The point is you may not need to use a built
>>in multiplier.
>>
>>Your filter seems very complex for a feedback filter.  Is there some
>>special need driving this?  Can you use a simpler filter?
>>
>>--
>>
>>Rick
> 
> I do not really know the value of P or how to determine it. I was
> thinking to use 0.99 because I tried it out in software simulation and
> it seems to do what I wanted it to do. The idea for this filter came
> from this article / second filter on Figure 2.
> 
> http://www.digitalsignallabs.com/dcblock.pdf
> 
> Someone said to forget equations and do as it is drawn in figure, but
> these figures never account for potential latency of the
> add/subtract/multiply blocks or if I do not add registers, then I may
> have timing issues.
> 
> Anyway, I will try to do add and multiply in one clock cycle and see
> where this gets me.
> 
> Thank you all very much anyhow.


I have successfully implemented a DC blocker in VHDL based on the 
information in that paper.  It was less that a page of VHDL.

Instead of multiplying by something like 0.99, multiply by (1-1/(2**N)) 
(for some fixed integer N, e.g. 6 or 7).  This can be done with just a 
shift and subtract, and the low pass filter can be done all in one clock 
cycle.

This is a DC blocker, after all, and the position of the pole probably 
isn't all that critical.

Regards,
Allan

Article: 158352
Subject: Re: DC Blocker
From: Tim Wescott <seemywebsite@myfooter.really>
Date: Fri, 23 Oct 2015 12:11:31 -0500
Links: << >>  << T >>  << A >>
On Fri, 23 Oct 2015 02:51:42 -0500, b2508 wrote:

>>On 10/22/2015 4:50 PM, b2508 wrote:
>>>> In article <2Z-dnUTCaKvCqLTLnZ2dnUU7-VOdnZ2d@giganews.com>,
>>>> b2508 <108118@FPGARelated> wrote:
>>>>> Hm.. I tought that multiplication cannot be implemented without
> delay.
>>>>>
>>>>> This could cause timing issues to my knowledge.
>>>>>
>>>>> Moreover, full formula is
>>>>>
>>>>> y[n] = Q {x[n] - x[n-1] + p*y[n-1] - e[n-1]}
>>>>> e[n] = x[n] - x[n-1] + p*y[n-1] - e[n-1] - y[n]
>>>>>
>>>>> Error is difference between output before and after quantization.
>>>>> I asked for the initial one because even that i don't know how to
>>>>> implement.
>>>>>
>>>>> if x1 appears at t1, corresponding y1 is ready at earlies at
> t2=t1+1.
>>If
>>> I
>>>>> register subtracting operation as well, e1 is available at t3=t1+1.
>>>>> However x2 arrives at t2 and neither y1 (corresponding y[n-1]) or e1
>>> are
>>>>> ready at that time.
>>>>
>>>> Without really looking at your required function in detail (just
> noting
>>>> that it has feedback terms) - I'll just note in general.
>>>>
>>>> The statement "multiplication cannot be implemented without delay" is
>>>> false, in many ways.  It all depends on your processing requirements.
>>>> What is your sample rate?  What are your bit widths?
>>>>
>>>> You're processing clock does NOT need to be the same as your sample
>>> clock.
>>>> If you wish them to be the same - it may be easier for new FPGA users
> to
>>>
>>>> design - then you MAY be able to run the multiplier full
>>>> combinational
> -
>>>
>>>> If you're sample rate is low enough.
>>>>
>>>> The alternative (at a high level) is to buffer an input and output,
> and
>>>> process with a faster processing clock.  Modern FPGA's these days can
>>run
>>>
>>>> DSP functions upwards to around 400-500 MHz.  This is likely much
> faster
>>>
>>>> than your sample rate.
>>>>
>>>> Regards,
>>>> Mark
>>>
>>> OK, I was taught that it is always safer to put registers wherever you
>>> can. I have no choice in my project but to have same sampling and
>>> processing rate.
>>>
>>> My rate is 100 MHz.
>>> Input data or x[n] has data format - unsigned, 16 bit, 1 bit for
> integer.
>>>
>>> Also, I am not sure how to select data widths after each of these
>>> operations.
>>>
>>> If x[n] and x[n-1] are 16/1 and their subtraction is 17 bit unsigned
> with
>>> 2 bit integers, how do I proceed with data width selection? Feedback
> loop
>>> part is unclear to me.
>>> Also, should I use DSP48 for the multiplication with P or should I
> make
>>it
>>> somehow power of two and do it by shifting?
>>>
>>> Q is quantization, or reducing number of samples after all these
>>> operations.
>>
>>Do you know the value of P?  Multiplies are done by shifting and adding.
> 
>>  I don't know which chip you are planning to use, but all the
>>multipliers I know of require pipelining, the only option is how many
>>stages, 1, 2, etc...  Since P is a constant (it *is* a constant, right?)
> 
>>you only need to use adders for the 1s, or if there are long runs of 1s
>>or 0s, you can subtract at the lsb of the run and add in at the bit just
> 
>>past the msb of the run.  The point is you may not need to use a built
>>in multiplier.
>>
>>Your filter seems very complex for a feedback filter.  Is there some
>>special need driving this?  Can you use a simpler filter?
>>
>>--
>>
>>Rick
> 
> I do not really know the value of P or how to determine it. I was
> thinking to use 0.99 because I tried it out in software simulation and
> it seems to do what I wanted it to do. The idea for this filter came
> from this article / second filter on Figure 2.
> 
> http://www.digitalsignallabs.com/dcblock.pdf
> 
> Someone said to forget equations and do as it is drawn in figure, but
> these figures never account for potential latency of the
> add/subtract/multiply blocks or if I do not add registers, then I may
> have timing issues.
> 
> Anyway, I will try to do add and multiply in one clock cycle and see
> where this gets me.

So, the set of equations that I suggested elsewhere pretty much implement 
what you claim to want, you can use d = 2^-N, which implies a shift, and 
-- as I stated -- you can use some delay in the "servo to average value" 
step.

So what's your problem again?

Equations reiterated:

u: input
y: output
x: state variable

y[n] = u[n] - x[n-1]
x[n] = d * y[n]

-- 

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

Article: 158353
Subject: Re: recovery/removal timing
From: "jt_eaton" <84408@FPGARelated>
Date: Fri, 23 Oct 2015 12:25:55 -0500
Links: << >>  << T >>  << A >>

>
>Apologies but can I ask if this reply is from an ASIC mindset or is it
>spam. Almost every statement doesn't make any sense whatsoever for
FPGAs.
>
>Zak
>---------------------------------------
>Posted through http://www.FPGARelated.com

Valid question. It is from an ASIC mindset and has nothing to do with
FPGA's. This entire thread has nothing to do with FPGA's

Xilinx recomends that you never use an asynchonous reset in your logic. 
Its expensive ( sync reset flops takes 3 LUT's while an async one takes
4). It's slow ( Xilinx has a app note on rtl programming styles that says
async resets can slow you down by a factor as high as 4. All those really
fast multiplier macros use sync reset so if you ask for async then it must
build them out of LUTs. It is also redundent. Your programming input is
asynchronous and leaves every flop in the design in a known state. That is
your power on asynchronous reset system. Adding a second one in logic
makes no sense at all.

I haven't read Altera docs but I suspect the same will apply


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

Article: 158354
Subject: Re: recovery/removal timing
From: "jt_eaton" <84408@FPGARelated>
Date: Fri, 23 Oct 2015 12:54:10 -0500
Links: << >>  << T >>  << A >>
>zak wrote:
>

>I just found a condition where you could have an un-synchronized input on
a
>
>product that has been in manufacture for a decade.  Normally, this signal
IS
>
>synchronized on the FPGA, but there was a particular configuration
involving
>
>multiple boards where it would be synched from the OTHER board, only. 
>OOPS!
>
>Jon

That goes to show that once you ship your product then it probably will
not see many resets during its lifetime. I've done embedded systems that
are always on and I suspect that few of them would ever see more than a
few dozen resets before they are trashed. Designers worry about resets all
the time but if you screw it up then it is very unlikely that the customer
will trigger a failure and extremely unlikely that they will do so twice
in a row. 

Turning it back off and on again can hide a lot of mistakes


John Eaton


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

Article: 158355
Subject: Re: recovery/removal timing
From: gtwrek@sonic.net (Mark Curry)
Date: Fri, 23 Oct 2015 18:30:48 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <K-6dnfZewNs-8LfLnZ2dnUU7-IudnZ2d@giganews.com>,
jt_eaton <84408@FPGARelated> wrote:
>
>>
>>Apologies but can I ask if this reply is from an ASIC mindset or is it
>>spam. Almost every statement doesn't make any sense whatsoever for
>FPGAs.
>>
>>Zak
>>---------------------------------------
>>Posted through http://www.FPGARelated.com
>
>Valid question. It is from an ASIC mindset and has nothing to do with
>FPGA's. This entire thread has nothing to do with FPGA's
>
>Xilinx recomends that you never use an asynchonous reset in your logic. 
>Its expensive ( sync reset flops takes 3 LUT's while an async one takes
>4). It's slow ( Xilinx has a app note on rtl programming styles that says
>async resets can slow you down by a factor as high as 4. All those really
>fast multiplier macros use sync reset so if you ask for async then it must
>build them out of LUTs. It is also redundent. Your programming input is
>asynchronous and leaves every flop in the design in a known state. That is
>your power on asynchronous reset system. Adding a second one in logic
>makes no sense at all.
>
>I haven't read Altera docs but I suspect the same will apply

A few nits, but the general gist is all good.  Async resets should be MINIMIZED
in Xilinx logic - but "never" isn't usually attainable.  Even in some Xilinx
app notes they're used.  

Why?- Well, using an async reset on a flop removes the requirement of a 
good clock.  That flop'll will be reset irrespective of the clock state.

So, many times in your clock and reset generation blocks, you'll likely need
the async resets on flops.

I also warn to be careful with assuming FPGA Config = Reset.  They're often 
NOT the same, and just relying on the former, can lead to some rather nasty
and long debug sessions.  My point here is that specifically including a
SYNCHRONOUS reset, in MOST of your logic is a wise design practice.  (Something
Xilinx discourages for optimal fpga use, but IMHO, they're just dead
wrong).

Regards,

Mark



Article: 158356
Subject: Re: recovery/removal timing
From: gtwrek@sonic.net (Mark Curry)
Date: Fri, 23 Oct 2015 18:36:53 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <-Jadnfhk6Ivf6bfLnZ2dnUU7-fednZ2d@giganews.com>,
jt_eaton <84408@FPGARelated> wrote:
>>zak wrote:
>>
>
>>I just found a condition where you could have an un-synchronized input on
>a
>>
>>product that has been in manufacture for a decade.  Normally, this signal
>IS
>>
>>synchronized on the FPGA, but there was a particular configuration
>involving
>>
>>multiple boards where it would be synched from the OTHER board, only. 
>>OOPS!
>>
>>Jon
>
>That goes to show that once you ship your product then it probably will
>not see many resets during its lifetime. I've done embedded systems that
>are always on and I suspect that few of them would ever see more than a
>few dozen resets before they are trashed. Designers worry about resets all
>the time but if you screw it up then it is very unlikely that the customer
>will trigger a failure and extremely unlikely that they will do so twice
>in a row. 
>
>Turning it back off and on again can hide a lot of mistakes

John, I agree with assertion, but not neccesarily your conclusions.
Yes, resets may not occur very often in you're devices.
But that IMHO, is more the reason to get it right.  

Murphy's law says that that one customer will hit the troublesome
case more often.  And since it's so fiddly, and hardly used
you don't have many datapoints on failures.  Meaning debugging's 
a bitch.

I pay close attention to reset and initialization.  Been
bitten by too many low probability errors that occur much
too late in the design cycle.  They're the devil to debug.


Regards,
Mark




Article: 158357
Subject: Re: Question about partial multiplication result in transposed FIR filter
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Fri, 23 Oct 2015 11:55:43 -0700 (PDT)
Links: << >>  << T >>  << A >>
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 a=
nd are not equivalent to them.

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

Article: 158358
Subject: Re: recovery/removal timing
From: rickman <gnuarm@gmail.com>
Date: Fri, 23 Oct 2015 14:57:31 -0400
Links: << >>  << T >>  << A >>
On 10/23/2015 1:25 PM, jt_eaton wrote:
>>
>> Apologies but can I ask if this reply is from an ASIC mindset or is it
>> spam. Almost every statement doesn't make any sense whatsoever for
> FPGAs.
>>
>> Zak
>> ---------------------------------------
>> Posted through http://www.FPGARelated.com
>
> Valid question. It is from an ASIC mindset and has nothing to do with
> FPGA's. This entire thread has nothing to do with FPGA's
>
> Xilinx recomends that you never use an asynchonous reset in your logic.
> Its expensive ( sync reset flops takes 3 LUT's while an async one takes
> 4). It's slow ( Xilinx has a app note on rtl programming styles that says
> async resets can slow you down by a factor as high as 4. All those really
> fast multiplier macros use sync reset so if you ask for async then it must
> build them out of LUTs. It is also redundent. Your programming input is
> asynchronous and leaves every flop in the design in a known state. That is
> your power on asynchronous reset system. Adding a second one in logic
> makes no sense at all.
>
> I haven't read Altera docs but I suspect the same will apply

I think you are a bit confused about the async reset.  Every FF in the 
fabric is connected to an async reset signal that spans the entire chip. 
  This is called (oddly enough) the Global Set/Reset or GSR in Xilinx 
devices.  It is always asserted during configuration and can also be 
driven by a user signal.

An async reset can be critical to restore a defined state to the design 
in the event the clock stops.  This signal is usually pretty slow and 
may be hard to get to meet system synchronous timing requirements.  The 
trick to proper use is to make sure there are other controls that 
maintain a reset state for the design when the async signal is removed. 
  These synchronous resets can apply to local sections of logic which 
must start up synchronized while usually the entire design does not. 
Then timing is more easily met.

-- 

Rick

Article: 158359
Subject: Quad-Port BlockRAM in Virtex
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Fri, 23 Oct 2015 12:40:40 -0700 (PDT)
Links: << >>  << T >>  << A >>
I think I need a quad-port blockRAM in a Xilinx V7.  Having multiple read p=
orts is no problem, but I need two read ports and two write ports.  The two=
 write ports is the problem.  I can't double the clock speed.  To be clear,=
 I need to be able to do two reads and two writes per cycle.  (Not writes t=
o the same address.)

The only idea I could come up with is to have four dual-port BRAMs and a se=
maphore array.  Let's call the BRAMs AC, AD, BC, and BD.  Writer A writes t=
he same value to address x in AC and AD and simultaneously sets the semapho=
re of address x to point to 'A'.  Now when reader C wants to read address x=
, it reads AC and BC and the semaphore, sees that semaphore points toward t=
he A side, and uses the value from AC and discards BC.  If writer B writes =
to address x, it writes the value to both BC and BD and sets the semaphore =
x to point to side B.  Reader D reads AD and BD and picks one based on the =
semaphore bit.

The semaphore itself is complicated.  I think it would consists of 2 quad-p=
ort RAMs, one bit wide and the depth of AC, each one having 1 write and 3 r=
ead ports.  This could be distributed RAM.  Writer A would read the side B =
semaphore bit and set its own to the same, and writer B would read the side=
 A bit and set its own to the opposite.  Now when reader C or D read their =
two copies (A/B) of the semaphore bits using their read ports, they check i=
f they are the same (use side A) or opposite (use side B).

It's a big mess and uses 4x the BRAMs as a dual-port.  Maybe I need a diffe=
rent solution.

Article: 158360
Subject: Re: Quad-Port BlockRAM in Virtex
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Fri, 23 Oct 2015 13:10:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
Update:  I found a solution in the "Altera Synthesis Cookbook" and it seems=
 to be the scheme I described above, but implementing the semaphore bits as=
 FFs instead of distributed RAM.  I'd need about 2048 semaphore bits, so im=
plementing that in a distributed RAM would probably be advantageous.  You c=
an do a 64-bit quad port (1 wr, 3 rd) in a 4-LUT slice, so I'd need 2048/64=
*4*2 =3D 256 LUTs to do 2 2048-bit quad-port distributed RAMs.  (Add in ~10=
 slices for 32->1 muxes.)

Article: 158361
Subject: Re: recovery/removal timing
From: gtwrek@sonic.net (Mark Curry)
Date: Fri, 23 Oct 2015 20:32:13 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <n0dvqo$m3p$1@dont-email.me>, rickman  <gnuarm@gmail.com> wrote:
>On 10/23/2015 1:25 PM, jt_eaton wrote:
>>>
>>> Apologies but can I ask if this reply is from an ASIC mindset or is it
>>> spam. Almost every statement doesn't make any sense whatsoever for
>> FPGAs.
>>>
>>> Zak
>>> ---------------------------------------
>>> Posted through http://www.FPGARelated.com
>>
>> Valid question. It is from an ASIC mindset and has nothing to do with
>> FPGA's. This entire thread has nothing to do with FPGA's
>>
>> Xilinx recomends that you never use an asynchonous reset in your logic.
>> Its expensive ( sync reset flops takes 3 LUT's while an async one takes
>> 4). It's slow ( Xilinx has a app note on rtl programming styles that says
>> async resets can slow you down by a factor as high as 4. All those really
>> fast multiplier macros use sync reset so if you ask for async then it must
>> build them out of LUTs. It is also redundent. Your programming input is
>> asynchronous and leaves every flop in the design in a known state. That is
>> your power on asynchronous reset system. Adding a second one in logic
>> makes no sense at all.
>>
>> I haven't read Altera docs but I suspect the same will apply
>
>I think you are a bit confused about the async reset.  Every FF in the 
>fabric is connected to an async reset signal that spans the entire chip. 
>  This is called (oddly enough) the Global Set/Reset or GSR in Xilinx 
>devices.  It is always asserted during configuration and can also be 
>driven by a user signal.
>
>An async reset can be critical to restore a defined state to the design 
>in the event the clock stops.  This signal is usually pretty slow and 
>may be hard to get to meet system synchronous timing requirements.  The 
>trick to proper use is to make sure there are other controls that 
>maintain a reset state for the design when the async signal is removed. 
>  These synchronous resets can apply to local sections of logic which 
>must start up synchronized while usually the entire design does not. 
>Then timing is more easily met.

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.

And back to the OP - I believe he was NOT referring to this GSR at all, but
to the normal Async reset on a FF i.e. (verilog)

always @( posedge clk or posedge reset )
  if( reset )
     q <= 0;
  else 
     q <= d;

This is the async flip flop, where clock recovery/removal timing checks
must be done, as was asked in the start of the thread.

Remove the "posedge reset" from the sensitivity list, and it's a 
synchronous reset, with just normal setup/hold checks.   Synchronous 
are preferred and much more efficient in today's FPGAs.

Regards,

Mark 
   


Article: 158362
Subject: Re: recovery/removal timing
From: rickman <gnuarm@gmail.com>
Date: Fri, 23 Oct 2015 22:30:04 -0400
Links: << >>  << T >>  << A >>
On 10/23/2015 4:32 PM, Mark Curry wrote:
> In article <n0dvqo$m3p$1@dont-email.me>, rickman  <gnuarm@gmail.com> wrote:
>> On 10/23/2015 1:25 PM, jt_eaton wrote:
>>>>
>>>> Apologies but can I ask if this reply is from an ASIC mindset or is it
>>>> spam. Almost every statement doesn't make any sense whatsoever for
>>> FPGAs.
>>>>
>>>> Zak
>>>> ---------------------------------------
>>>> Posted through http://www.FPGARelated.com
>>>
>>> Valid question. It is from an ASIC mindset and has nothing to do with
>>> FPGA's. This entire thread has nothing to do with FPGA's
>>>
>>> Xilinx recomends that you never use an asynchonous reset in your logic.
>>> Its expensive ( sync reset flops takes 3 LUT's while an async one takes
>>> 4). It's slow ( Xilinx has a app note on rtl programming styles that says
>>> async resets can slow you down by a factor as high as 4. All those really
>>> fast multiplier macros use sync reset so if you ask for async then it must
>>> build them out of LUTs. It is also redundent. Your programming input is
>>> asynchronous and leaves every flop in the design in a known state. That is
>>> your power on asynchronous reset system. Adding a second one in logic
>>> makes no sense at all.
>>>
>>> I haven't read Altera docs but I suspect the same will apply
>>
>> I think you are a bit confused about the async reset.  Every FF in the
>> fabric is connected to an async reset signal that spans the entire chip.
>>   This is called (oddly enough) the Global Set/Reset or GSR in Xilinx
>> devices.  It is always asserted during configuration and can also be
>> driven by a user signal.
>>
>> An async reset can be critical to restore a defined state to the design
>> in the event the clock stops.  This signal is usually pretty slow and
>> may be hard to get to meet system synchronous timing requirements.  The
>> trick to proper use is to make sure there are other controls that
>> maintain a reset state for the design when the async signal is removed.
>>   These synchronous resets can apply to local sections of logic which
>> must start up synchronized while usually the entire design does not.
>> Then timing is more easily met.
>
> 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.
>
> And back to the OP - I believe he was NOT referring to this GSR at all, but
> to the normal Async reset on a FF i.e. (verilog)
>
> always @( posedge clk or posedge reset )
>    if( reset )
>       q <= 0;
>    else
>       q <= d;
>
> This is the async flip flop, where clock recovery/removal timing checks
> must be done, as was asked in the start of the thread.
>
> Remove the "posedge reset" from the sensitivity list, and it's a
> synchronous reset, with just normal setup/hold checks.   Synchronous
> are preferred and much more efficient in today's FPGAs.

If the OP is talking about using the async reset of individual FFs, I 
can offer no advise.  I have never encountered a situation where I 
needed that.

-- 

Rick

Article: 158363
Subject: Found: an FPGA with internal tri-states
From: Aleksandar Kuktin <akuktin@gmail.com>
Date: Sat, 24 Oct 2015 14:38:51 +0000 (UTC)
Links: << >>  << T >>  << A >>
In has been mentioned here a few times that there are no FPGAs with 
internal tristates. However, surfing around somewhat aimlessly, I 
stumbled upon a device series which has them and obviously had to share 
my find:

The Atmel AT40K and AT40KAL series.

OTOH, their gate delay is pretty big: around 1.2 ns, and their SRAM read 
times aren't much better at about 10 ns. I didn't dig much deeper into 
the datasheets so far.

Article: 158364
Subject: Re: Found: an FPGA with internal tri-states
From: rickman <gnuarm@gmail.com>
Date: Sat, 24 Oct 2015 10:55:50 -0400
Links: << >>  << T >>  << A >>
On 10/24/2015 10:38 AM, Aleksandar Kuktin wrote:
> In has been mentioned here a few times that there are no FPGAs with
> internal tristates. However, surfing around somewhat aimlessly, I
> stumbled upon a device series which has them and obviously had to share
> my find:
>
> The Atmel AT40K and AT40KAL series.
>
> OTOH, their gate delay is pretty big: around 1.2 ns, and their SRAM read
> times aren't much better at about 10 ns. I didn't dig much deeper into
> the datasheets so far.

This is a truly ancient FPGA family and you would use them at your own 
risk.  I'd be very surprised if they didn't come with a caution: Not for 
New Designs.  I think they are at least 15 years old, no?  I haven't 
looked them up, but I bet they are pretty expensive too.

-- 

Rick

Article: 158365
Subject: Re: Found: an FPGA with internal tri-states
From: Gabor Szakacs <gabor@alacron.com>
Date: Sat, 24 Oct 2015 11:08:16 -0400
Links: << >>  << T >>  << A >>
On 10/24/2015 10:55 AM, rickman wrote:
> On 10/24/2015 10:38 AM, Aleksandar Kuktin wrote:
>> In has been mentioned here a few times that there are no FPGAs with
>> internal tristates. However, surfing around somewhat aimlessly, I
>> stumbled upon a device series which has them and obviously had to share
>> my find:
>>
>> The Atmel AT40K and AT40KAL series.
>>
>> OTOH, their gate delay is pretty big: around 1.2 ns, and their SRAM read
>> times aren't much better at about 10 ns. I didn't dig much deeper into
>> the datasheets so far.
>
> This is a truly ancient FPGA family and you would use them at your own
> risk.  I'd be very surprised if they didn't come with a caution: Not for
> New Designs.  I think they are at least 15 years old, no?  I haven't
> looked them up, but I bet they are pretty expensive too.
>

If you want another old FPGA with internal tristate that is still in
production, check out Xilinx Spartan 2.  It's also 5V tolerant...

-- 
Gabor

Article: 158366
Subject: Re: Found: an FPGA with internal tri-states
From: Johann Klammer <klammerj@NOSPAM.a1.net>
Date: Sat, 24 Oct 2015 17:21:43 +0200
Links: << >>  << T >>  << A >>
On 10/24/2015 04:38 PM, Aleksandar Kuktin wrote:
> In has been mentioned here a few times that there are no FPGAs with 
> internal tristates. However, surfing around somewhat aimlessly, I 
> stumbled upon a device series which has them and obviously had to share 
> my find:
> 
> The Atmel AT40K and AT40KAL series.
> 
> OTOH, their gate delay is pretty big: around 1.2 ns, and their SRAM read 
> times aren't much better at about 10 ns. I didn't dig much deeper into 
> the datasheets so far.
> 
A while back i tried verifying the available documentation 
against the bitstreams their IDS software produces. 
Got most of the details figured out.

there it is:
<https://github.com/klammerj/iverilog/tree/master/tgt-slick/util/wigglepuppy>



Article: 158367
Subject: Re: recovery/removal timing
From: "jt_eaton" <84408@FPGARelated>
Date: Sat, 24 Oct 2015 11:14:49 -0500
Links: << >>  << T >>  << A >>

All of us learn our craft starting off with small designs that we take
through each design stage all the way to a working product. But real life
is different. Real designs are far to large for any single engineer to do
the entire thing so we use several engineers with each one assigned to do
a different task.

Those tasks are:


Component Designers who create the leaf cell designs


Architects who select the leaf cells, configure and interconnect them


Board designers who design the printed circuit assembly




When you work by yourself it is tempting to look ahead and try to take
care of issues that will arise in the next phase of the design process. DO
NOT DO THIS. While I am sure that you are a competent engineer and that
the engineer who was assigned that task will be happy that you decided to
butt in and do his job for him it you should rmember that some people are
sensitive about this.

If its not your job then you don't get to make those decisions.


 

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

The way it works is that you need to do an asynchronous assert and a
synchronous deassert. Your assert resets all user flops but sets all the
flops in your synchronous reset system into their assert state. Your user
flop will clear to 0 and it will have a 0 on its D input from the
synchronous reset system.

Nothing will happen when you deassert your asynchronous reset because you
will still have the synchronous one active. That one will deassert over
time and will be synchronous to the flops clock.

You design it by finding out the longest path from your asynchronous input
pin to every flop in your chip. Double that time ( we like to sandbag our
designs) and  divide it by your reference clock period. That gives you the
number of clock cycles that you have to maintain the synchronous reset
after you deassert your asynchronus reset. That takes care of your slow
removal because each flop will still be controlled by the synchronous
reset.




>
>always @( posedge clk or posedge reset )
>  if( reset )
>     q <= 0;
>  else 
>     q <= d;
>

You see this alot in designs. Component designers are obsessed with making
sure that their designs get reset so they build every flop with an
asynchronous reset port and connnect them all directly to the boards power
on reset signal.

Theres just one little problem. Component designers do not own the reset
system design, It now belongs to other engineers and you are  doing their
job for them. They are not happy. With a top down design they tell you
what to do, you do not get to tell them what to do.


What should you do instead.


always @( posedge clk or negedge reset_n )

  if      (! reset_n )   q <= 0;
  else if (  reset   )   q <= 0;
  else                   q <= d;

If you do this then the architects are no longer locked into your reset
design. If they want it then they can tie the reset inactive and they have
your design. They could also tie the reset_n inactive and have a
completely synchronous design or they could as I have suggested use both.
If you use both then the design is dft clean and you are not messing up
your timing the way the your design does.


So who does own the reset system design?

The board designer


The board designer is responsible for creating the board's power on reset
signal. They look at all the power supplies and debounce the reset button
to create a single active low open drain signal. They then route that
signal to every chip on the board. If a chip doesn't have a reset input
then they route it through the chip controlling it. They stitch together
the products reset system from the reset systems of all the chips on the
board.

Finally they add the ESD filtering and the design is complete. The board
designer has the complete engineering responsibility for the products
power on reset system.

Now heres where the problem comes in. Component designers are obsessed
with making sure that each flop is reset while the reset button is
depressed. But we surveyed every board designer who had ever done that job
and none of them were worried about that at all.

Sure it gets screwed up every now and then but our digital tools are good
enough that you will always find the problem and fix it before release.
Its not a problem. What is a problem that keeps the board designers up at
nite is ESD. You can't even begin to test for that until you have real
silicon, PCBs and case parts. By the time you get those you are well past
the point where you should be making changes to your design.


So your boss is obsessed with making sure that the product does not reset
while the reset button is NOT pressed and you are designing to the exact
opposite requirement. 

Thats why I get so annoyed with engineers who insist that a complete
asynchronous reset system is the only way to go. For one thing there are
other equivaltent options that they have not considered and second of all
they do not get to decide how to do it. Its not their job.


John Eaton









 













  
























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

Article: 158368
Subject: Re: DC Blocker
From: Richard Damon <Richard@Damon-Family.org>
Date: Sat, 24 Oct 2015 12:22:24 -0400
Links: << >>  << T >>  << A >>
On 10/23/15 1:11 PM, Tim Wescott wrote:
>
> Equations reiterated:
>
> u: input
> y: output
> x: state variable
>
> y[n] = u[n] - x[n-1]
> x[n] = d * y[n]
>

Something can't be right with these equations.

Let us say we have had signal for awhile with a DC component.

u[n] now goes to that value.

By definition, y[n] should be 0, and thus so would x[n]

if u[n+1] has that same value again, y[n+1] = u[n+1] and not 0 as required,

The equations I tend to use for something like this is:

y[n]= u[n] = x[n-1]
x[n] = x[n-1] + k*y[n]

(k being some power of 0.5 so the multiply is a shift.)
x often needing additional fractional bits, especially if k is very small.

Article: 158369
Subject: ML405 Xilinx ISE 14.7
From: abirov@gmail.com
Date: Sat, 24 Oct 2015 11:14:01 -0700 (PDT)
Links: << >>  << T >>  << A >>
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'.
ERROR:MapLib:30 - LOC constraint P16 on SW2 is invalid: No such site on the
   device. To bypass this error set the environment variable 'XIL_MAP_LOCWARN'.
ERROR:MapLib:30 - LOC constraint M11 on SW3 is invalid: No such site on the
   device. To bypass this error set the environment variable 'XIL_MAP_LOCWARN'.
ERROR:MapLib:30 - LOC constraint N11 on SW4 is invalid: No such site on the
   device. To bypass this error set the environment variable 'XIL_MAP_LOCWARN'.
ERROR:MapLib:30 - LOC constraint M10 on SW5 is invalid: No such site on the
   device. To bypass this error set the environment variable 'XIL_MAP_LOCWARN'.
ERROR:MapLib:30 - LOC constraint M9 on SW6 is invalid: No such site on the
   device. To bypass this error set the environment variable 'XIL_MAP_LOCWARN'.
ERROR:MapLib:30 - LOC constraint N8 on SW7 is invalid: No such site on the
   device. To bypass this error set the environment variable 'XIL_MAP_LOCWARN'.
ERROR:MapLib:30 - LOC constraint N7 on SW8 is invalid: No such site on the
   device. To bypass this error set the environment variable 'XIL_MAP_LOCWARN'.
ERROR:MapLib:30 - LOC constraint P10 on vga_b_out<0> is invalid: No such site on
   the device. To bypass this error set the environment variable
   'XIL_MAP_LOCWARN'.
ERROR:MapLib:30 - LOC constraint P11 on vga_b_out<1> is invalid: No such site on
   the device. To bypass this error set the environment variable
   'XIL_MAP_LOCWARN'.
ERROR:MapLib:30 - LOC constraint R8 on vga_b_out<2> is invalid: No such site on
   the device. To bypass this error set the environment variable
   'XIL_MAP_LOCWARN'.
ERROR:MapLib:30 - LOC constraint N9 on vga_g_out<0> is invalid: No such site on
   the device. To bypass this error set the environment variable
   'XIL_MAP_LOCWARN'.
ERROR:MapLib:30 - LOC constraint N6 on vga_g_out<1> is invalid: No such site on
   the device. To bypass this error set the environment variable
   'XIL_MAP_LOCWARN'.
ERROR:MapLib:30 - LOC constraint P6 on vga_g_out<2> is invalid: No such site on
   the device. To bypass this error set the environment variable
   'XIL_MAP_LOCWARN'.
ERROR:MapLib:30 - LOC constraint R6 on vga_r_out<0> is invalid: No such site on
   the device. To bypass this error set the environment variable
   'XIL_MAP_LOCWARN'.
ERROR:MapLib:30 - LOC constraint R7 on vga_r_out<1> is invalid: No such site on
   the device. To bypass this error set the environment variable
   'XIL_MAP_LOCWARN'.
ERROR:MapLib:30 - LOC constraint P9 on vga_r_out<2> is invalid: No such site on
   the device. To bypass this error set the environment variable
   'XIL_MAP_LOCWARN'.

Article: 158370
Subject: ERROR:MapLib:30 - LOC constraint P11 on vga_b_out<1> is invalid: No
From: abirov@gmail.com
Date: Sat, 24 Oct 2015 11:25:35 -0700 (PDT)
Links: << >>  << T >>  << A >>
Dear all first of all want thanx to everyone who belong to this forum and give help to each other.

I use Xilinx ISE 14.7, and ML405 

I checked ML405's schematic that pins, and are exist,i used advise 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'.
ERROR:MapLib:30 - LOC constraint P16 on SW2 is invalid: No such site on the
   device. To bypass this error set the environment variable 'XIL_MAP_LOCWARN'.
ERROR:MapLib:30 - LOC constraint M11 on SW3 is invalid: No such site on the
   device. To bypass this error set the environment variable 'XIL_MAP_LOCWARN'.
ERROR:MapLib:30 - LOC constraint N11 on SW4 is invalid: No such site on the
   device. To bypass this error set the environment variable 'XIL_MAP_LOCWARN'.
ERROR:MapLib:30 - LOC constraint M10 on SW5 is invalid: No such site on the
   device. To bypass this error set the environment variable 'XIL_MAP_LOCWARN'.
ERROR:MapLib:30 - LOC constraint M9 on SW6 is invalid: No such site on the
   device. To bypass this error set the environment variable 'XIL_MAP_LOCWARN'.
ERROR:MapLib:30 - LOC constraint N8 on SW7 is invalid: No such site on the
   device. To bypass this error set the environment variable 'XIL_MAP_LOCWARN'.
ERROR:MapLib:30 - LOC constraint N7 on SW8 is invalid: No such site on the
   device. To bypass this error set the environment variable 'XIL_MAP_LOCWARN'.
ERROR:MapLib:30 - LOC constraint P10 on vga_b_out<0> is invalid: No such site on
   the device. To bypass this error set the environment variable
   'XIL_MAP_LOCWARN'.
ERROR:MapLib:30 - LOC constraint P11 on vga_b_out<1> is invalid: No such site on
   the device. To bypass this error set the environment variable
   'XIL_MAP_LOCWARN'.
ERROR:MapLib:30 - LOC constraint R8 on vga_b_out<2> is invalid: No such site on
   the device. To bypass this error set the environment variable
   'XIL_MAP_LOCWARN'.
ERROR:MapLib:30 - LOC constraint N9 on vga_g_out<0> is invalid: No such site on
   the device. To bypass this error set the environment variable
   'XIL_MAP_LOCWARN'.
ERROR:MapLib:30 - LOC constraint N6 on vga_g_out<1> is invalid: No such site on
   the device. To bypass this error set the environment variable
   'XIL_MAP_LOCWARN'.
ERROR:MapLib:30 - LOC constraint P6 on vga_g_out<2> is invalid: No such site on
   the device. To bypass this error set the environment variable
   'XIL_MAP_LOCWARN'.
ERROR:MapLib:30 - LOC constraint R6 on vga_r_out<0> is invalid: No such site on
   the device. To bypass this error set the environment variable
   'XIL_MAP_LOCWARN'.
ERROR:MapLib:30 - LOC constraint R7 on vga_r_out<1> is invalid: No such site on
   the device. To bypass this error set the environment variable
   'XIL_MAP_LOCWARN'.
ERROR:MapLib:30 - LOC constraint P9 on vga_r_out<2> is invalid: No such site on
   the device. To bypass this error set the environment variable
   'XIL_MAP_LOCWARN'. 

Article: 158371
Subject: Re: recovery/removal timing
From: "kaz" <37480@FPGARelated>
Date: Sat, 24 Oct 2015 22:22:39 -0500
Links: << >>  << T >>  << A >>
>All of us learn our craft starting off with small designs that we take
>through each design stage all the way to a working product. But real
life
>is different. Real designs are far to large for any single engineer to
do
>the entire thing so we use several engineers with each one assigned to
do
>a different task.
>
>Those tasks are:
>
>
>Component Designers who create the leaf cell designs
>
>
>Architects who select the leaf cells, configure and interconnect them
>
>
>Board designers who design the printed circuit assembly
>
>
>
>
>When you work by yourself it is tempting to look ahead and try to take
>care of issues that will arise in the next phase of the design process.
DO
>NOT DO THIS. While I am sure that you are a competent engineer and that
>the engineer who was assigned that task will be happy that you decided
to
>butt in and do his job for him it you should rmember that some people
are
>sensitive about this.
>
>If its not your job then you don't get to make those decisions.
>
>
> 
>
>>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

>Thats why I get so annoyed with engineers who insist that a complete
>asynchronous reset system is the only way to go. For one thing there are
>other equivaltent options that they have not considered and second of
all
>they do not get to decide how to do it. Its not their job.
>
>
>John Eaton

Inside fpga there might be several clock domains and the fpga engineer is
responsible to synchronise reset to all domains. So it is internal
responsibilty and even if it is one clock domain it is much easier to do
that sort of work inside fpga.

You certainly need reset otherwise you will have power up variation or
variation per reset release if not applied properly. But some registers
may not need it. It is certainly vital for state machines and control
registers but for data paths if data value is irrelevant for any control
logic.

One thing I find it misunderstood is that reset whether applied through D
input(mis-named synchronous) or through async port must be viewed as
asynchronous from its origin if it can arrive independent of clock.



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

Article: 158372
Subject: Re: DC Blocker
From: "kaz" <37480@FPGARelated>
Date: Sat, 24 Oct 2015 22:45:45 -0500
Links: << >>  << T >>  << A >>
op links to this doc
http://www.digitalsignallabs.com/dcblock.pdf

looking into above document I got a bit curious; to get rid of truncation
dc
bias why add fraction of truncation when you can just use rounding to
nearest integer or to nearest even.

Kaz

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

Article: 158373
Subject: Re: Found: an FPGA with internal tri-states
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sun, 25 Oct 2015 05:38:46 +0000 (UTC)
Links: << >>  << T >>  << A >>
Aleksandar Kuktin <akuktin@gmail.com> wrote:

> In has been mentioned here a few times that there are no FPGAs with 
> internal tristates. However, surfing around somewhat aimlessly, I 
> stumbled upon a device series which has them and obviously had to share 
> my find:
 
> The Atmel AT40K and AT40KAL series.
 
> OTOH, their gate delay is pretty big: around 1.2 ns, and their SRAM read 
> times aren't much better at about 10 ns. I didn't dig much deeper into 
> the datasheets so far.

Internal tristates don't scale properly. As the chips get bigger,
and wires get smaller, the delay increases too much.

For unidirectional wires, there are buffers along the way, but you
can't buffer lines with tristates. 

But you don't need to worry.  The usual synthesis tools will
generate wire-AND (or maybe wire-OR) logic if you write tri-state
logic.

If you are implementing existing logic designs, it is easy enough
to allow the synthesis tools to process them. If not, it is easy
enough to write wire-AND logic.  (At least is is in verilog,
I haven't tried in VHDL yet.)

-- glen

Article: 158374
Subject: Re: ML405 Xilinx ISE 14.7
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sun, 25 Oct 2015 05:41:11 +0000 (UTC)
Links: << >>  << T >>  << A >>
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



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