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 92975

Article: 92975
Subject: Re: FPGA : MAP slice logic into BLOCK RAM
From: wv9557@yahoo.com
Date: 10 Dec 2005 06:57:01 -0800
Links: << >>  << T >>  << A >>
First off, I think it's better to instantiate BRAM than inferring it.
When you go to the restaurant
and you want veal, you should say it, don't describe the veal to the
waiter :)
The other issue is that your FFs are read from and written to in the
same clock. I vaguely
remember reading and writing to the same BRAM address is a bad idea.

bijoy wrote:
> Hi
>
> I have read that, it says we should not use asynchronous reset
>
> The program what i have written is also taken from there and they say it will be mapped to BRAMs
>
> I am observing in my p&r report that it is getting mapped to BRAM but the slice count is not getting reduced.
> 
> regds bijoy


Article: 92976
Subject: Re: Is it legal to write an logical equation for a FPGA LUT in claims of a patent?
From: "raul" <raulizahi@gmail.com>
Date: 10 Dec 2005 07:49:39 -0800
Links: << >>  << T >>  << A >>
Anything that is divulged in a public forum can constitute "prior art".
 I have been part of a counter-legal action related to postings I have
made.  So keep posting away if you want to be "prior art" and hope that
the "truth" will come through at some point.

RAUL
Not An Attorney


Article: 92977
Subject: Re: Securing verilog source code
From: "fad" <fahad.arif@gmail.com>
Date: 10 Dec 2005 09:02:29 -0800
Links: << >>  << T >>  << A >>
Thanks Hans,
I will try this out.


Article: 92978
Subject: Re: ISE purchase
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Sat, 10 Dec 2005 17:28:43 +0000 (UTC)
Links: << >>  << T >>  << A >>
On Fri, 09 Dec 2005 16:42:18 GMT, "Roger" <enquiries@rwconcepts.co.uk>
wrote:

>I need to buy a license for ISE Foundation to support some VIIPro work I'm 
>doing. Would it make any difference to the price if I went via a distributor 
>here in the UK or just bought online via the Xilinx web site? Anyone have 
>any comments?

Won't make a whole lot of difference in price; the distributor would
handle VAT if appropriate, versus the shipper.

I'm all in favour of supporting the local guy. But getting a UK
distributor to respond to a phone call in less than a week can be a
challenge. If you manage that, and they quote you a lead time for
Foundation in excess of six weeks, why not just go ahead and order
online?

The worst that will happen is a phone call from the shipper, asking for
VAT/import + 30 handling fee before they can release the goods.

- Brian


Article: 92979
Subject: Re: Post PAR Simulation and Actual FPGA results differ
From: juendme@yahoo.com
Date: 10 Dec 2005 09:45:45 -0800
Links: << >>  << T >>  << A >>

Sudhir.Singh@email.com wrote:
> Thanks for the reply.
> Yeah I am giving the FSM a clean sycnhronous reset and the inputs are
> all sychronous. I'll test for the FSM going into illegal state.
>
> Sudhir

You could also use Chipscope Pro to monitor the signals on chip. That
may help you see what's going wrong. You can get free evaluation
version on the Xilinx web site


Article: 92980
Subject: Re: Adding "super-LUTs" to FPGA, good idea ?
From: juendme@yahoo.com
Date: 10 Dec 2005 10:31:41 -0800
Links: << >>  << T >>  << A >>

Sylvain Munaut wrote:

> And here I was more referring to the drive strenght than the number of
> input nets. For example if you have to generate a clock ena
> combinatorially (just a single LUT level but still) and it controls like
>  50 FFs, the net take like 1.5 ns propagation ... half of my period ...
>


I don't know if your initial idea is feasible or not, but it sounds
good to me.

In the meantime, you can reduce the fanout (at cost) by using logic
duplication. If you duplicate the signal and drive only half the flip
flops, that should improve your timing (at the increased cost in terms
of area).
You can do that in one of two ways:
1. Manually (in your code) create two signals, and set options so that
your synthesis tool does not optimize redundant logic
2. Turn on logic duplication,and hope the synthesis tool will recognize
that the critical path can be improved by duplicating that piece of
logic

Fred


Article: 92981
Subject: Re: No, not FIFOs again...
From: Ray Andraka <ray@andraka.com>
Date: Sat, 10 Dec 2005 14:09:34 -0500
Links: << >>  << T >>  << A >>
Thomas Entner wrote:
> Hi Peter,
> 
> your reply made me think... I assumed that with gray-codes I am safe for 
> mismatches from one count to the next, but not if the skew between the bits 
> is more than one complete cycle, because than two bits might be wrong 
> instead of only one. Now I made a gray-code-table on a sheet of paper and I 
> found no situation where even this would be "catastrophic", because even 
> then the count is only of by 1 or 2. (But I think, it can lead to wrong or 
> "jumping" level-indication, even when the effects in the final application 
> are most likely of no concern.)
> 
> However, still a controlled delay between this register stages would give me 
> a better feeling, as otherwise you never can know how long the delay of the 
> fill-level-indicator is.

Yes, that is a hidden danger with passing more than one bit across a 
clock domain.  The propagation paths across the domain do have to be 
constrained to ensure the skew between them does not come even close to 
a full clock period of the faster clock domain.

Article: 92982
Subject: Re: Adding "super-LUTs" to FPGA, good idea ?
From: Kolja Sulimma <news@sulimma.de>
Date: Sat, 10 Dec 2005 23:13:07 +0100
Links: << >>  << T >>  << A >>
Sylvain Munaut schrieb:
> So what if every now and then in the FPGA fabric, there was a small
> cluster of like 1 CLB with "Super LUTs" that would have a whole lot
> faster logic (but no special func like SRL and distributed ram) and
> "bigger" drivers to charge/dischare the net faster to propagate the
> controls.
Well, there are couple of 14-Input LUTs in their newer devices. The
speed is about 2ns in Virtex-4.
They call them BRAMs.

Kolja Sulimma

Article: 92983
Subject: Re: ISE purchase
From: "Stephen Craven" <scraven@vt.edu>
Date: 10 Dec 2005 14:51:00 -0800
Links: << >>  << T >>  << A >>
I realize this is a basic question, but I couldn't find a simple answer
on the Xilinx site.

What is the difference between Foundation, Base X, and Webpack?

Does more $$$ mean more applications are included, or does more $$$
mean better applications are included?

Thanks!
Stephen


Article: 92984
Subject: Re: Post PAR Simulation and Actual FPGA results differ
From: "info_" <"info_"@\\nospam_no_underscore_alse-fr.com>
Date: Sun, 11 Dec 2005 00:32:58 +0100
Links: << >>  << T >>  << A >>
Sudhir.Singh@email.com wrote:
  However when I run the design on
> actual FPGA the registers are not updated and design doesn't behave
> correctly.

Did you check that ALL you inputs to the FSM (including indeed
the Clock Enable !) are properly re-synchronized ?
This is probably the most common design error. I see it everyday.

Hope this helps,

Bert

Article: 92985
Subject: Re: No, not FIFOs again...
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 10 Dec 2005 15:50:21 -0800
Links: << >>  << T >>  << A >>
Without trying to sound defensive:
That's exactly what I implied by writing

"In other words, you don't have to be super-fast, as long as you meet
the required (synchronous) timing constraints, determined by the clock
rates."

Sloppiness that exceeds a clock period will of course always get you in
trouble...
Peter Alfke, from home


Article: 92986
Subject: Re: Adding "super-LUTs" to FPGA, good idea ?
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 10 Dec 2005 15:57:08 -0800
Links: << >>  << T >>  << A >>
And one of those dual-ported BRAMs can be
either
two identical, but independently addressable, 14-input LUTs,
or two completely different, independent 13-input LUTs.
Naturally...
Peter Alfke


Article: 92987
Subject: re:Job available... 2 projects
From: fahadislam2002@hotmail-dot-com.no-spam.invalid (fahadislam2002)
Date: Sat, 10 Dec 2005 19:15:43 -0600
Links: << >>  << T >>  << A >>
I have experience in both PCB Designing , Digital Designing(FPGA based
designing).I am also there to do that challenge ... in short time ,
more relavent to requirements and more cheeper as well ...  :)


Article: 92988
Subject: MMC(MultiMedia Card) interfacing with FPGA
From: fahadislam2002@hotmail-dot-com.no-spam.invalid (fahadislam2002)
Date: Sat, 10 Dec 2005 19:15:43 -0600
Links: << >>  << T >>  << A >>
Hi 
    We are trying to interface a 16MB MMC(of Infineon) to Spartan-2
FPGA ... 
We have designed reader for card(in VHDL) abopting MMC protocol(not
SPI) and this card is supports 2.7 to 3.0 standard ...
    Before designing its writer i want to test reader ...
and before that i want your suggestions ... :)  

So please share your experience and guide me ...

                       Thanks


Article: 92989
Subject: Re: MMC(MultiMedia Card) interfacing with FPGA
From: "Antti Lukats" <antti@openchip.org>
Date: Sun, 11 Dec 2005 09:19:19 +0100
Links: << >>  << T >>  << A >>
"fahadislam2002" <fahadislam2002@hotmail-dot-com.no-spam.invalid> schrieb im 
Newsbeitrag news:kdqdnV-4CqYi4AbeRVn_vA@giganews.com...
> Hi
>    We are trying to interface a 16MB MMC(of Infineon) to Spartan-2
> FPGA ...
> We have designed reader for card(in VHDL) abopting MMC protocol(not
> SPI) and this card is supports 2.7 to 3.0 standard ...
>    Before designing its writer i want to test reader ...
> and before that i want your suggestions ... :)
>
> So please share your experience and guide me ...
>
>                       Thanks
>

so whats your problem ??
why are "trying" and not "DOING" ??

I have published an project at opencores that can configure an FPGA from MMC 
in MMC mode this IPcore is hardware tested (uses 21 PLD macrocells!)

at
http://gforge.openchip.org

there is snapshot from mmc host controller ip core from LARK project - 
notice that ipcore is 100% non-tested

and www.xilant.com
has MMC/SD cardside ipcore that could be used for testing (not announced 
yet)

for initial testing you can just make an Microblaze SoC in the S-2 and use 
bitbang to read the MMC so it would be easy to debug and see the response, I 
think I published once that software but dont recall where and if it is 
still on the web, in any case it isnt complex

so go ahead and test you mmc interface, until you do that, you would not 
know if it works or not

Antti







Article: 92990
Subject: Re: ISE purchase
From: "John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk>
Date: Sun, 11 Dec 2005 10:05:01 -0000
Links: << >>  << T >>  << A >>
Generally the major difference is in the devices supported by the tool. 
Foundation supports all current devices. BaseX a smaller set and Webpack 
smaller again. Webpack has also got some of the power user tools like FPGA 
Editor removed. Comparision here 
http://www.xilinx.com/ise/devsys_feature_guide.pdf .

John Adair
Enterpoint Ltd. - Home of Raggedstone1. The Very Low Cost Spartan-3 
Development Board.
http://www.enterpoint.co.uk

"Stephen Craven" <scraven@vt.edu> wrote in message 
news:1134255059.938545.255950@g49g2000cwa.googlegroups.com...
>I realize this is a basic question, but I couldn't find a simple answer
> on the Xilinx site.
>
> What is the difference between Foundation, Base X, and Webpack?
>
> Does more $$$ mean more applications are included, or does more $$$
> mean better applications are included?
>
> Thanks!
> Stephen
> 



Article: 92991
Subject: About Spartan 3
From: "Piotr Wyderski" <wyderski@mothers.against.spam-ii.uni.wroc.pl>
Date: Sun, 11 Dec 2005 12:06:10 +0100
Links: << >>  << T >>  << A >>
I would like to build an universal measurement device, composed of
a frequency meter and a bus protocol analyser (among other things).
It will be based on a Spartan 3 chip, i.e. XC3S200-4TQ144C, which
is the largest S3 device I can buy in very small quantities without problems
(with Cyclone 2 the situation is much worse... :-( ). I have never used
Xilinx parts before, so could you please answer the following, perhaps
trivial, questions?

1. What is the highest frequency I can measure using that part
    a) without any tricks;
    b) with some tricks -- I know that Peter Alfke has implemented
    a freqency meter capable of 450MHz on an S2(?). :-)

2. Is it possible to obtain some information about the bitstream format
of that particular chip? The device should support all the IO modes that
Spartans support, which implies about 30 different configuration files...
However, I believe that the only thing that needs different configuration
settings is the IOB subsystem, since the rest of the device remains
unchanged.
So I would like to dynamically patch the bitstream by an on-board
microcontroller, which will generate an appropriate stream from a single
configuration file template. But where is the IO configuration part of the
stream and how is it encoded? Note: I don't want any warranties etc.
from Xilinx and I know that the format could be changed in the future,
but I am only interested in the format of the chip I hold in my hand.

    Best regards
    Piotr Wyderski


Article: 92992
Subject: Re: Free x86 IP-Core is really working!
From: "Antti Lukats" <antti@openchip.org>
Date: Sun, 11 Dec 2005 12:38:20 +0100
Links: << >>  << T >>  << A >>

"Hans" <hans64@ht-lab.com> schrieb im Newsbeitrag 
news:PtSlf.6121$E14.3906@newsfe7-win.ntli.net...
> Hi Antti,
>
> I am happy to see you managed to get it up and running although using the 
> serial port might have been easier than using chipscope. I will add an 
> 8254 and 8259 (required for a minimum system) as soon as my workload 
> reduces a bit (probably around Christmas) If only I had some more "spare" 
> time...... :-)
>
> Regards,
> Hans.
> www.ht-lab.com
>

Hi Hans,

it wasnt so complex, but for those who would like to speed test drive it I 
just uploaded the ISE Virtex4 project I used in testing, its basically just 
the files from your website with minor fixes to get it working in Virtex4

http://xilant.com/content/view/20/55/
there is the IP-Core "Review" and link to the project archive

Antti



Article: 92993
Subject: Re: About Spartan 3
From: "Antti Lukats" <antti@openchip.org>
Date: Sun, 11 Dec 2005 12:50:30 +0100
Links: << >>  << T >>  << A >>

"Piotr Wyderski" <wyderski@mothers.against.spam-ii.uni.wroc.pl> schrieb im 
Newsbeitrag news:dnh17b$v6k$1@news.dialog.net.pl...
>I would like to build an universal measurement device, composed of
> a frequency meter and a bus protocol analyser (among other things).
> It will be based on a Spartan 3 chip, i.e. XC3S200-4TQ144C, which
> is the largest S3 device I can buy in very small quantities without 
> problems
> (with Cyclone 2 the situation is much worse... :-( ). I have never used
> Xilinx parts before, so could you please answer the following, perhaps
> trivial, questions?
>
> 1. What is the highest frequency I can measure using that part
>    a) without any tricks;
>    b) with some tricks -- I know that Peter Alfke has implemented
>    a freqency meter capable of 450MHz on an S2(?). :-)
>
> 2. Is it possible to obtain some information about the bitstream format
> of that particular chip? The device should support all the IO modes that
> Spartans support, which implies about 30 different configuration files...
> However, I believe that the only thing that needs different configuration
> settings is the IOB subsystem, since the rest of the device remains
> unchanged.
> So I would like to dynamically patch the bitstream by an on-board
> microcontroller, which will generate an appropriate stream from a single
> configuration file template. But where is the IO configuration part of the
> stream and how is it encoded? Note: I don't want any warranties etc.
> from Xilinx and I know that the format could be changed in the future,
> but I am only interested in the format of the chip I hold in my hand.
>
>    Best regards
>    Piotr Wyderski
>
http://gforge.openchip.org/projects/fpgafreqmeter/

there is frequency meter that can be implemented in just any FPGA
we have some real world measurement results (no tricks)

Spartan3 -4 speedgrade: 420MHz (that was the highest clock I was able to 
feed into..)
Virtex4: 970 MHz

if you want to "patch" the bitstream, well we have an bit2frames application 
that
can be used to compare the bits and query the locations, and we had planned 
an

bitpatch

what could in turn to be used to post patch the biststreams just for the 
purpose
you mentioned, please contact in private if you are interested in this

Antti













Article: 92994
Subject: Re: MMC(MultiMedia Card) interfacing with FPGA
From: "Kryten" <kryten_droid_obfusticator@ntlworld.com>
Date: Sun, 11 Dec 2005 15:22:30 GMT
Links: << >>  << T >>  << A >>
"Antti Lukats" <antti@openchip.org> wrote in message 
news:dngni1$olv$1@online.de...
> I have published an project at opencores that can configure an FPGA from 
> MMC in MMC mode this IPcore is hardware tested (uses 21 PLD macrocells!)

Ah, the Verilog one. Very useful project.
I hope to get it booting my own project.

> http://gforge.openchip.org
> there is snapshot from MMC host controller IP core from LARK project - 
> notice that ipcore is 100% non-tested

Very nice, I've just downloaded that!

I've got ideas for using that too.
Looks like it is for a 32-bit wide data bus, I'd like to mod it for humble 
8-bitters.

#> and www.xilant.com
> has MMC/SD cardside ipcore that could be used for testing (not announced 
> yet)

I look forward to it.

I hear SD is a superset of MMC.

SD details are harder to come by without NDA or licences, but presumably if 
you don't use the 'secure' features then it will just look like an MMC card 
with 4-bit wide data bus?

Cheers, K.



Article: 92995
Subject: Re: MMC(MultiMedia Card) interfacing with FPGA
From: "Antti Lukats" <antti@openchip.org>
Date: Sun, 11 Dec 2005 16:30:30 +0100
Links: << >>  << T >>  << A >>
"Kryten" <kryten_droid_obfusticator@ntlworld.com> schrieb im Newsbeitrag 
news:WuXmf.5709$XZ6.534@newsfe1-gui.ntli.net...
> "Antti Lukats" <antti@openchip.org> wrote in message 
> news:dngni1$olv$1@online.de...
>> I have published an project at opencores that can configure an FPGA from 
>> MMC in MMC mode this IPcore is hardware tested (uses 21 PLD macrocells!)
>
> Ah, the Verilog one. Very useful project.
> I hope to get it booting my own project.
>
this is one really works !

>> http://gforge.openchip.org
>> there is snapshot from MMC host controller IP core from LARK project - 
>> notice that ipcore is 100% non-tested
>
> Very nice, I've just downloaded that!
>
I think there is small bug in CRC7 and maybe something else
as said its presented in the way I got it, and its completly untested

> I've got ideas for using that too.
> Looks like it is for a 32-bit wide data bus, I'd like to mod it for humble 
> 8-bitters.
>
go ahead :)

> #> and www.xilant.com
>> has MMC/SD cardside ipcore that could be used for testing (not announced 
>> yet)
>
> I look forward to it.
>
:) me too

> I hear SD is a superset of MMC.
>
somewhat

> SD details are harder to come by without NDA or licences, but presumably 
> if you don't use the 'secure' features then it will just look like an MMC 
> card with 4-bit wide data bus?
>
> Cheers, K.
>
no exactly

SD and MMC have the same mmc like communication protocol what by default is 
1 bit

SD has somewhat different command set meaning that some commands that are 
present
in MMC are not there in SD like streaming read is only in MMC not in SD
also the initialization is different

both MMC and SD can turn on 4 bit mode
additionally MMC (standard 4.1) can also support 8 bit mode and turbo clock 
up to 52MHz !

Antti


































Article: 92996
Subject: Re: MMC(MultiMedia Card) interfacing with FPGA
From: "Kryten" <kryten_droid_obfusticator@ntlworld.com>
Date: Sun, 11 Dec 2005 15:52:14 GMT
Links: << >>  << T >>  << A >>
"Antti Lukats" <antti@openchip.org> wrote in message 
news:dnhgmj$q4f$01$1@news.t-online.com...

>>> http://gforge.openchip.org
> I think there is small bug in CRC7 and maybe something else
> as said its presented in the way I got it, and its completely untested
>

>> I hear SD is a superset of MMC.
>>
> SD has somewhat different command set meaning that some commands that are 
> present
> in MMC are not there in SD like streaming read is only in MMC not in SD
> also the initialization is different

Sigh. SD cards seem to be the best thing to buy for most consumer 
electronics, they seem to be replacing MMC cards. Better data bus width etc.

Any recommendations for documentation describing MMC, SD, and their 
differences. I have Googled, and got swamped with loads of links to places 
selling such cards. The few techy links were fairly useless, along the lines 
of "you can buy the full spec from...."


> both MMC and SD can turn on 4 bit mode

http://www.howell1964.freeserve.co.uk/parts/sd_mm.htm
indicates MMC has only 7 pins, and only one of these for data.

> additionally MMC (standard 4.1) can also support 8 bit mode and turbo 
> clock up to 52MHz !

Wow.

I thought most of the 'new features' work would be done on SD cards.
The Mini-format is just a repackaging.




Article: 92997
Subject: Re: Xilinx Coregen IP Customizer Causes Exception During Customization
From: "Brian" <brian_704@yahoo.com>
Date: 11 Dec 2005 13:17:32 -0800
Links: << >>  << T >>  << A >>
According to this page, ISE Webpack does not support the Core
Generator.

http://www.xilinx.com/ise/products/webpack_config.htm

Maybe they'll change their policy with 8.1. It would be nice if they
had an informative error message about this. It's funny how some of the
IP works by just installing the updates.

Brian

dean.dunnigan@gmail.com wrote:
> Hi Fred:
>
> I am also getting the same error.  Interestingly enough, I am using the
> same version of ISE,  same IP update, and same version of Windows XP.
> I've also tried Dual Port Block Mem versions 6.1 and 6.2 in the CoreGen
> tool and get the same error.  In my application, I am targetting a
> VirtexII.
>
> I'm not aware of any work-arounds but also hoping someone can jump in
> and provide suggestions!
> 
> 
> Dean.


Article: 92998
Subject: Important BRAM safety tip ( was: Adding "super-LUTs" to FPGA, good idea ?)
From: "Brian Davis" <brimdavis@aol.com>
Date: 11 Dec 2005 15:49:18 -0800
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> And one of those dual-ported BRAMs can be either
> two identical, but independently addressable, 14-input LUTs,
> or two completely different, independent 13-input LUTs.

An important "Danger Will Robinson" observation on using BRAMS:

 If you violate setup/hold on the address inputs of an enabled BRAM,
EVEN IF WE IS INACTIVE, BRAM contents can (will) be corrupted.

This means:
 - No multicycles (unless you use EN).
 - No async inputs.
 - TIMING CONSTRAINTS ARE A NECCESSITY!!!

IF BRAM TIMING CONSTRAINTS ARE NOT SET PROPERLY,
AND MET, BRAM CONTENTS WILL BE CORRUPTED!!!

See Answer Record 21870
"Virtex-II/-II Pro/-4 block RAM - Do the setup/hold times for the
Address inputs need to be met, even if the output is unused and
WE is deasserted?"

Brian


Article: 92999
Subject: Re: Important BRAM safety tip ( was: Adding "super-LUTs" to FPGA, good idea ?)
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 11 Dec 2005 16:31:33 -0800
Links: << >>  << T >>  << A >>
Brian, I think you overdramatize this.
(I was involved in finding and explaining this behavior a few weeks
ago).

Anybody who writes into the BRAM must of course abide by the address
set-up time requirement.
Anybody who reads from the BRAM must also abide by the address set-up
time requirement.
The surprising, non-obvious requirement is that, if the BRAM is
enabled, a violation of the address set-up time can corrupt data, even
though WE remained disabled.
So, do NOT change the address right before the enabled active clock
edge.
You would obviously not do this when you are writing, and you wouldn't
do it when you are reading, but you must also not do it when you have
the BRAM clock-enabled and read-enabled and you really do not care
about the result of the uncontrolled read operation. The easy way out
of it is to disable the clock, not just WE.

Thisis a highly unusual (but explainable) restriction, so unusual that
neither Xilinx nor any customer  found it for many years.
Peter Alfke, Xilinx Applications




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