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 93000

Article: 93000
Subject: Re: Important BRAM safety tip ( was: Adding "super-LUTs" to FPGA, good idea ?)
From: "Brian Davis" <brimdavis@aol.com>
Date: 11 Dec 2005 17:07:25 -0800
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
>
> Brian, I think you overdramatize this.
>
Hardly- it should be mentioned front and center in the BRAM
sections of the datasheet and user guides; in bold print; with
circles and arrows and a paragraph on the back explaining
the problem.

 Adopting the same head-in-the-sand, "it's in an Answer Record
somewhere", mentality that, of recent years, has pervaded
Xilinx's approach to documenting serious problems, does not
help your customers one whit.

>
> 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 thread in question was about using BRAMS as logic.

Who would expect a ROM to clobber its' own contents due to an
address setup violation?

Brian


Article: 93001
Subject: Re: Important BRAM safety tip ( was: Adding "super-LUTs" to FPGA, good idea ?)
From: Bob Perlman <bobsrefusebin@hotmail.com>
Date: Sun, 11 Dec 2005 17:45:05 -0800
Links: << >>  << T >>  << A >>
On 11 Dec 2005 16:31:33 -0800, "Peter Alfke" <alfke@sbcglobal.net>
wrote:

>Brian, I think you overdramatize this.

I have to agree with Brian.  This is a big deal.  I expected that
violating read address setup time would screw up the read result that
cycle; I was amazed to find out that violating address timing could
actually change the contents of the RAM.  I imagine that anyone using
the BRAM as a ROM, with WE arc-welded to ground, would be doubly
surprised.

I have a design in which different buses supply the read and write
addresses to a large number of BRAMs.  The write address is
synchronized; the read address isn't, because  I saw no reason to, at
least until I saw Answer Record 21870 (which I saw only by accident,
thanks to a tip from another designer).  Even then, it took about a
week and a half working with the Hotline and an FAE before I found out
what the Answer Record actually meant, the original version having
been more vague than the current one.  So I've got a design that I
have to redo.

The "easy way out of the problem" is easy only if you know there's a
problem in the first place.

I heard from the Hotline that the data sheets for the affected
families would be amended.  If amended data sheets haven't been
released already, I hope they will be soon.

I guess the thing that bothers me the most is that once the problem
was identified, no one at Xilinx seemed to know that when RAMs don't
work like RAMs, it's potentially a Big Damn Deal for at least some
designers, and deserving of something more than to be hidden away in
an Answer Record that you might or might not see.

Bob Perlman
Cambrian Design Works

Article: 93002
Subject: Re: Important BRAM safety tip ( was: Adding "super-LUTs" to FPGA,
From: Jim Granville <no.spam@designtools.co.nz>
Date: Mon, 12 Dec 2005 15:28:44 +1300
Links: << >>  << T >>  << A >>
Brian Davis wrote:
Peter Alfke wrote:
<snip>
>>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 thread in question was about using BRAMS as logic.
> 
> Who would expect a ROM to clobber its' own contents due to an
> address setup violation?

Valid point.
  Reminds me of an oops Philips made in their UARTS,
which was a Test mode kicked into by READ [?!] of a certain address.
  So, yes, without care on the selection lines, this could go
out-to-lunch. Took them a while to admit to it.....

  Another issue here, is if this IS loaded/used as a ROM,
what happens during brownout, where it is quite possible that timing MAY 
be violated.
  Sounds like there could be a lot of ?? space between
the 'Let's Reconfigure' decision point, and the 'Inside Specs'
operate point ?

-jg


Article: 93003
Subject: Re: Important BRAM safety tip ( was: Adding "super-LUTs" to FPGA, good idea ?)
From: "Brian Davis" <brimdavis@aol.com>
Date: 11 Dec 2005 19:00:13 -0800
Links: << >>  << T >>  << A >>
Jim wrote:
>   Another issue here, is if this IS loaded/used as a ROM,
> what happens during brownout, where it is quite possible that timing MAY
> be violated.

 Or if the BlockROM clock is sourced by a DCM which goes unlocked,
thus rendering all BlockROM contents unreliable until the device has
been reconfigured.

Oops.

Better not use that XST BRAM_MAP logic-into-BRAM mapping option
any time soon...

Brian


Article: 93004
Subject: Re: Problem with ChipScope Pro 6.2
From: Anup Raghavan <pionup@hotmail.com>
Date: Mon, 12 Dec 2005 13:53:22 +1030
Links: << >>  << T >>  << A >>
Hello Sudhir, I too had this same problem. I followed the info from the 
Xilinx support site to help me get over this problem.

http://www.xilinx.com/xlnx/xil_ans_display.jsp?BV_UseBVCookie=yes&getPagePath=19578


Answers Database

6.2i ChipScope Pro - XCF00P/Platform Flash in chain gives 0 core units 
found by ChipScope Analyzer
Answer Record: 	19578
Family: 	Software
Product Line: 	FPGA Implementation
Part: 	ChipScope Pro
Version: 	6.2i
Last Modified: 	11/23/04 11:15:27
Status: 	Active
Rate This Answer
Very Useful
Useful
Not Useful Click to submit
Email this page 	Email this page
Send us feedback 	Feedback
Print 	Print Version

Problem Description:

Keywords: xcf32p, analyzer, PROM, core, unit, found

Urgency: Standard

General Description:
If a XCF08/16/32P is in a JTAG chain, ChipScope cannot initialize the 
chain as it has no idea of what the instruction register length is. It 
will try to recognize the device as a XC18V00, but the instruction 
register is too small (8 bits). The parallel Platform Flash devices are 
16 bits.

Solution 1:

To work around this issue, edit the 
"%XILINX%\ChipScope_Pro_6_2i\data\deviceid.lst" and add the following 2 
lines:

C,505,93=XCF00P
XCF00P=10

However I did have to change the IR Length field in the "JTAG Chain 
device order dialog box" to 16 for my Virtex2Pro part to get it working.

Good luck.
Anup

Sudhir.Singh@email.com wrote:
> Hi All,
> I just got myself an evaluation license for ChipScope Pro 6.2. I used
> the Core Inserter tool to insert the ICON and ILA cores into my design.
> The first time I used the Pro Analyser to load the configuration file
> it all went ok. However, I tried to load the same configuration file
> the next day and now Analyser gives me the following messsage:
> 
> COMMAND: configure 1 "C:\my_design_cs.bit" 0
> INFO: Found 0 Core Units in the JTAG device Chain
> 
> The configuration file hasn't been changed.
> I have tried multiple times but no luck.
> Has anybody else had the same problem? Is this some sort of limitation
> put on ChipScope evaluation version? 
> 
> Thanks in advance
> Sudhir
> 

Article: 93005
Subject: When read back bitstreams from Xilinx PROMs, how to verify?
From: "Frank" <Francis.invalid@hotmail.com>
Date: Mon, 12 Dec 2005 11:41:11 +0800
Links: << >>  << T >>  << A >>
I am reading back bitstreams from PROMs (5 xc18v04 and 1 xc18v02 in a chain)
since I lost the
original copy (mixed up with other bitstreams). How do I verify the readback
copy is correct?

I only have one board and the good bitstream is already saved in PROMs.
Reprogramimg them
back into the same board is risking losing them.




Article: 93006
Subject: Hello PPl, is there a way of locking a design (NGC) to a particular FPGA board?
From: jaxato@gmail.com
Date: 11 Dec 2005 19:59:27 -0800
Links: << >>  << T >>  << A >>
We have a very good and expensive design that we want to give freely,
as an NGC file, with our generic FPGA products. How can we make the
design work only on our board.

Our current technology is S3 and the user needs to be able to compile
their project with our NGC file, but on OUR fpga product.

I thought of keeping a key in an external serial memory, but this is
futile if the netlist cost $100K.

Again, the points are:

Very expensive and useful NGC file
Want to avoid reverse engineer and copy to other FPGA stations
What should the best solution be.

Well if we had some die ID, we could hardwired it to the netlist, so
that it checks that everytime it runs.

Any suggestion from you ppl?

Merry xmas and a happy new year 2006 to all of you!
JA


Article: 93007
Subject: Re: Important BRAM safety tip ( was: Adding "super-LUTs" to FPGA,
From: Ray Andraka <ray@andraka.com>
Date: Sun, 11 Dec 2005 23:42:07 -0500
Links: << >>  << T >>  << A >>
Bob Perlman wrote:
> On 11 Dec 2005 16:31:33 -0800, "Peter Alfke" <alfke@sbcglobal.net>
> wrote:
> 
> 
>>Brian, I think you overdramatize this.
> 
> 
> I have to agree with Brian.  This is a big deal.  I expected that
> violating read address setup time would screw up the read result that
> cycle; I was amazed to find out that violating address timing could
> actually change the contents of the RAM.  I imagine that anyone using
> the BRAM as a ROM, with WE arc-welded to ground, would be doubly
> surprised.


I'm with Brian and Bob on this.  As a designer, we need have limitations 
like this as well as those with the FIFO16's printed in bold right in 
the users guides so that it can be avoided by design rather than 
discovered in the lab.  Findng it in the lab is too late in the design 
cycle.  The question is, what other gems like this are hidden away in 
obscure answer records?

Article: 93008
Subject: who can help me? i want to know the bitsream format of Virtex-II
From: lioupayphone@gmail.com
Date: 11 Dec 2005 21:00:21 -0800
Links: << >>  << T >>  << A >>
if anyone know and is going to give me a hand, many thanks here!


Article: 93009
Subject: Re: who can help me? i want to know the bitsream format of Virtex-II
From: "Frank" <Francis.invalid@hotmail.com>
Date: Mon, 12 Dec 2005 13:22:37 +0800
Links: << >>  << T >>  << A >>

<lioupayphone@gmail.com> wrote in message
news:1134363621.432976.167570@g44g2000cwa.googlegroups.com...
> if anyone know and is going to give me a hand, many thanks here!
>

It's binary format, but you can see the design file name, chip ID and date &
time of creation in the first
64 bytes if you open it in winhex editor.




Article: 93010
Subject: Re: FPGA : MAP slice logic into BLOCK RAM
From: bijoy <pbijoy@rediffmail.com>
Date: Sun, 11 Dec 2005 22:32:31 -0800
Links: << >>  << T >>  << A >>
Hi I don't know how to implement a shift register using BRAMs. That is why i tried to use the map property to enable the mapping option.

If any one has an idea, could you please share it with me.

regards bijoy

Article: 93011
Subject: Re: Why does two channels of ADC give different outputs?
From: "Frank" <Francis.invalid@hotmail.com>
Date: Mon, 12 Dec 2005 14:56:34 +0800
Links: << >>  << T >>  << A >>

"Frank" <Frank@Frank.com> wrote in message
news:dmk525$34f$1@reader01.singnet.com.sg...
>
> "Meindert Sprang" <mhsprang@NOcustomSPAMware.nl> wrote in message
> news:11oqpeup6ur1k50@corp.supernews.com...
> > "Frank" <Francis.invalid@hotmail.com> wrote in message
> > news:438d4f5d$1@news.starhub.net.sg...
> >> In my digital side, I have a PHY_EN pin which is high when the digital
> >> circuit repetitively sends
> >> out same data, and the digital circuits work for 30us and idle for
10us.
> > On
> >> logic analyzer, I set
> >> the LA to start filling in the internal memory (256K) once PHY_EN is
> >> high,
> >> thus I can capture
> >> 20 repetitions. I am sure the data capture is correct.
> >
> > And I am not. this PHY_EN signal, what does it drive on the processor?
> > I can imagine that it just signals the processor data is available and
> > that
> > consequently, the processor issues bus cycles (set an address or CE,
> > activate RD, read data, deactivate Rd and CE) to read the data. This
means
> > that data on the bus during this 30us is not data from the ADC all the
> > time.
> > Only when the ADC is read during the bus read cycle, valid ADC data is
> > readable on the bus.
> >
> > Meindert
> >
> >
>
> Ah! I understand what you mean now. PHY_EN is a stable signal, while my
> clock
> period is 25ns, in each frame, digital side is sending some 1200 I/Q
> samples,
> one pair of samples each cycle and unchanged throughout the clock cycle.
>
> From the datasheet of ADC, I don't see there is any Rd or CD signal, it's
as
> plain as ADC outputs are hold stable and change every 25ns.
>
> After all is done, I think I had better flag a "faulty ADC board" message
to
> the up layer. since even when I disconnect ADC input, many of the pins
> mentioned
> below still to high level, sampled by a logic analyzer's 400MHz clock.
>
> Left channel,
> bit 7,5 stick to 0, bit 9,4 switches during active, stick to 1 in idle
mode,
> bit 8,6,3,2 switches during
> active, stick to 0 during idle (I expect 9:2 of both channel to behave in
> this manner), bit 1:0 are
> switching during idle and active (noise during idle mode).
>
>
>

Sigh! What should I say!!! After working a number of times, I realized that
the
god damned LA strobes are broken, and managed to sort out the broken ones
with an everchanging pin. With this discovery, I think I will get on much
easier.





Article: 93012
Subject: Re: ISE = Intelligent Synthesis Expectable :-)
From: backhus <nix@nirgends.xyz>
Date: Mon, 12 Dec 2005 08:30:07 +0100
Links: << >>  << T >>  << A >>

> A single line with the default, right before the case statement
> in DCM_comb, should do it:
> 
>    DCM_NextState <= DCM_CurrentState;
> 
> Jan
> 
Hi Jan,
You are right. I also thought about that, but somehow I expected it to 
create latches as well. Strange, since I'm using the 
defaults-before-case style a lot. Fooled by too much routine possibly :-)

But still, ISE created a latch free result before that change.
Maybe one could complain about a missing warning.
And even after the proposed correction ISE created a smaller and faster 
result than Precision RTL. (Synopsys dc also created something latchfree 
but again the FSM extraction failed, so further optimisation wasn't 
possible)

How comes that the simpler(?) tool does the better job?

Enlightened, but still wondering :-)

   Eilert



Article: 93013
Subject: Re: Hello PPl, is there a way of locking a design (NGC) to a particular FPGA board?
From: "Thomas Stanka" <usenet_10@stanka-web.de>
Date: 11 Dec 2005 23:33:38 -0800
Links: << >>  << T >>  << A >>
Why Ngc?
And is it necessary to stay on S3? Maybe you should think about Flash
based Fpgas (Actel, Lattice,..).

bye Thomas


Article: 93014
Subject: Re: Adding "super-LUTs" to FPGA, good idea ?
From: "Morten Leikvoll" <mleikvol@yahoo.nospam>
Date: Mon, 12 Dec 2005 10:00:28 +0100
Links: << >>  << T >>  << A >>

"Sylvain Munaut" <com.246tNt@tnt> wrote in message 
news:439a1f11$0$24466$ba620e4c@news.skynet.be...
> Ray Andraka wrote:
.... (stuff deleted)
> Well, yes optimizing control is good but sometimes very hard ... I've
> basically spent the last few days just doing that to finally meet
> timing. My comparators are not for counters but to detect a "empty"
> condition in a FIFO like block. ('FIFO like' because it's quite more
> complicated than a simple FIFO).

I have the same problem with the high clock to output. I found that when 
putting the signal through a delay (SRL16's) I can actually detect zero 
condition BEFORE going in, and shift the zero signal with the same delay. In 
theory I can detect some bits at each shift, making it very fast. When using 
RAMB I can also detect zero condition on any port and reserve a bit for 
that.



Article: 93015
Subject: Question about Xilinx UCF files
From: "=?iso-8859-1?B?R2FMYUt0SWtVc5k=?=" <taileb.mehdi@gmail.com>
Date: 12 Dec 2005 01:15:53 -0800
Links: << >>  << T >>  << A >>
In some reference design (ppc system on Xilinx ML403 board) I found the
following contraints in the UCF file:
# GPLED 0-3
NET gpio<0>  LOC = G5;  #GPLED0
NET gpio<1>  LOC = G6;  #GPLED1
NET gpio<2>  LOC = A11; #GPLED2
NET gpio<3>  LOC = A12; #GPLED3
NET "gpio<*>" PULLDOWN;
NET "gpio<*>" TIG;
NET "gpio<*>" SLEW = SLOW;
NET "gpio<*>" DRIVE = 2;

These I/Os are connected to LEDs.
The I/O standard is not mentionned ... I know that for LEDs that
doesn't really matter. But by default which standard will be used?
The ML403 contains a xc4vfx12-10ff668 FPGA (Virtex-4 FX12)

A+
Mehdi


Article: 93016
Subject: Re: Question about Xilinx UCF files
From: "Antti Lukats" <antti@openchip.org>
Date: Mon, 12 Dec 2005 10:57:33 +0100
Links: << >>  << T >>  << A >>
"GaLaKtIkUsT" <taileb.mehdi@gmail.com> schrieb im Newsbeitrag 
news:1134378953.648606.127860@g47g2000cwa.googlegroups.com...
> In some reference design (ppc system on Xilinx ML403 board) I found the
> following contraints in the UCF file:
> # GPLED 0-3
> NET gpio<0>  LOC = G5;  #GPLED0
> NET gpio<1>  LOC = G6;  #GPLED1
> NET gpio<2>  LOC = A11; #GPLED2
> NET gpio<3>  LOC = A12; #GPLED3
> NET "gpio<*>" PULLDOWN;
> NET "gpio<*>" TIG;
> NET "gpio<*>" SLEW = SLOW;
> NET "gpio<*>" DRIVE = 2;
>
> These I/Os are connected to LEDs.
> The I/O standard is not mentionned ... I know that for LEDs that
> doesn't really matter. But by default which standard will be used?
> The ML403 contains a xc4vfx12-10ff668 FPGA (Virtex-4 FX12)
>
> A+
> Mehdi
>

just open the pad report file and look it up
the defaults are different for different families

antti 



Article: 93017
Subject: modelsim settings in edk
From: Christoph Lauer <eem@rommel.stw.uni-erlangen.de>
Date: Mon, 12 Dec 2005 12:00:47 +0100
Links: << >>  << T >>  << A >>
hi,

I want to generate simulationlibrarys from edk 6.3 the wizard tells me I 
have to set the environment variable for modelsim. how do I do this in 
edk? thank you.

Article: 93018
Subject: Re: MMC(MultiMedia Card) interfacing with FPGA
From: "Martin Schoeberl" <mschoebe@mail.tuwien.ac.at>
Date: Mon, 12 Dec 2005 13:14:59 +0100
Links: << >>  << T >>  << A >>
> 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...."
>
http://www.sdcard.org/sd_memorycard/index.html
http://www.sandisk.com/pdf/oem/AppNoteMMC_SDv1.0.pdf

BTW: will your MMC or SD card interface be open-source?
I am interested in the SD card interface, ?but don't find
the time to implement it.

Martin 



Article: 93019
Subject: Re: MMC(MultiMedia Card) interfacing with FPGA
From: "Antti Lukats" <antti@openchip.org>
Date: Mon, 12 Dec 2005 13:54:08 +0100
Links: << >>  << T >>  << A >>
"Martin Schoeberl" <mschoebe@mail.tuwien.ac.at> schrieb im Newsbeitrag 
news:439d69c8$0$11610$3b214f66@tunews.univie.ac.at...
>> 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...."
>>
> http://www.sdcard.org/sd_memorycard/index.html
> http://www.sandisk.com/pdf/oem/AppNoteMMC_SDv1.0.pdf
>
> BTW: will your MMC or SD card interface be open-source?
> I am interested in the SD card interface, ?but don't find
> the time to implement it.
>
> Martin
>
Hi Martin,

your question was to whom?

if you want a SD card interface for your JOP, then firstly it can be done 
100% in software (I guess you are talking about the host side).

the SW version can be painfully slow depending on the CPU and compiler being 
used and coding style

for better speed one combo option could be that CMD line eg all 
command-response is handled in sw bitbang and only the DAT (eg block 
read/write) is implemented in hardware this would give very small FPGA core 
and only have a minor penalty on the speed. for this purpose the LARK mmc 
vhdl code archive actually contains allmost ready to use block (but I think 
the crc16 is also wrong there), in any case its not a major issue to design 
module that can rec-transmit the mmc style commands from-to block ram

Antti 



Article: 93020
Subject: Re: MMC(MultiMedia Card) interfacing with FPGA
From: "Antti Lukats" <antti@openchip.org>
Date: Mon, 12 Dec 2005 13:56:19 +0100
Links: << >>  << T >>  << A >>

"Kryten" <kryten_droid_obfusticator@ntlworld.com> schrieb im Newsbeitrag 
news:OWXmf.4434$zt1.198@newsfe5-gui.ntli.net...
> "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...."
>
there are enough specs to be find with DEEPgoogling

>
>> 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.
>
both mmc and sd have new things

MMC has rs-mmc format, also microMMC
and the 8 bit mode and turbo speed

SD has miniSD and microSD (aga Transflash)

OMHO the only card to be used is microSD :)

Antti
















Article: 93021
Subject: Re: modelsim settings in edk
From: Christoph Lauer <eem@rommel.stw.uni-erlangen.de>
Date: Mon, 12 Dec 2005 14:13:15 +0100
Links: << >>  << T >>  << A >>
hi,,

perhaps I have to refine my question:
I am trying to simulate a opb-slave using modelsim, therefore I need to 
"generate simulation hdl files" in edk. where can I set the environment 
vars of MODELSIM so that the wizard can do his work?
thanks a lot...

Christoph Lauer wrote:

> hi,
> 
> I want to generate simulationlibrarys from edk 6.3 the wizard tells me I 
> have to set the environment variable for modelsim. how do I do this in 
> edk? thank you.

Article: 93022
Subject: Re: MMC(MultiMedia Card) interfacing with FPGA
From: "Martin Schoeberl" <mschoebe@mail.tuwien.ac.at>
Date: Mon, 12 Dec 2005 14:16:30 +0100
Links: << >>  << T >>  << A >>
>>> 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...."
>>>
>> http://www.sdcard.org/sd_memorycard/index.html
>> http://www.sandisk.com/pdf/oem/AppNoteMMC_SDv1.0.pdf
>>
>> BTW: will your MMC or SD card interface be open-source?
>> I am interested in the SD card interface, ?but don't find
>> the time to implement it.
>>
>> Martin
>>
> Hi Martin,

Hi Antti,

>
> your question was to whom?

Who ever wants to provide it ;-)

>
> if you want a SD card interface for your JOP, then firstly it can be done 100% in software (I guess you are talking about the host 
> side).

That's the way I (or everybody else) would implement it first.
And than when it works one usually 'forgets' to ove it to HW.

>
> the SW version can be painfully slow depending on the CPU and compiler being used and coding style
>
> for better speed one combo option could be that CMD line eg all command-response is handled in sw bitbang and only the DAT (eg 
> block read/write) is implemented in hardware this would give very small FPGA core and only have a minor penalty on the speed. for 
> this purpose the LARK mmc vhdl code archive actually contains allmost ready to use block (but I think the crc16 is also wrong 
> there), in any case its not a major issue to design module that can rec-transmit the mmc style commands from-to block ram

Yes, a practical idea.

Martin



Article: 93023
Subject: Re: Question about Xilinx UCF files
From: "=?iso-8859-1?B?R2FMYUt0SWtVc5k=?=" <taileb.mehdi@gmail.com>
Date: 12 Dec 2005 05:47:20 -0800
Links: << >>  << T >>  << A >>
Thanks a lot Antti. Just forgot about the pad report!
It used LVCMOS25.

Thanks again!

A+
Mehdi


Article: 93024
Subject: Re: modelsim settings in edk
From: "=?iso-8859-1?B?R2FMYUt0SWtVc5k=?=" <taileb.mehdi@gmail.com>
Date: 12 Dec 2005 05:54:25 -0800
Links: << >>  << T >>  << A >>
In windows platform go to:
-The control pannel=>Performance and Maintenance=>System
-On My computer right clic=>properties
Go to the advanced tab and choose environment variables.

In Linux: add "export MODELSIM=PATH_YOU_WANT" in the /etc/profile file.

A+
Mehdi




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