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 86575

Article: 86575
Subject: PROM Generation question
From: "jimgeorge at gmail dot com" <jimgeorge@gmail.com>
Date: 30 Jun 2005 05:23:58 -0700
Links: << >>  << T >>  << A >>
    I wanted to generate a set of .MCS files for a Xilinx XC2V3000
design, the board uses three XC18V04 PROMs in serial mode, the PROMs
and the FPGA are on the same chain. I entered the prom config into
Impact in File Generation mode, but my design is small (bit file is 1.5
MB in size), so the utility informed me that only one .MCS file is
actually generated. Now back in JTAG mode, when I initialize the JTAG
chain, it asks me to associate a file with each device, so I can put in
the first MCS file into the first PROM,  but what about the others? Can
I just BYPASS them or do I need to do something else to make this work?
I'm a bit paranoid about burning up the device, so I didn't want to try
anything without asking here first. Thanks!
    -Jim


Article: 86576
Subject: Re: PROM Generation question
From: =?ISO-8859-1?Q?Johan_Bernsp=E5ng?= <xjohbex@xfoix.se>
Date: Thu, 30 Jun 2005 14:51:53 +0200
Links: << >>  << T >>  << A >>
jimgeorge at gmail dot com wrote:
>     I wanted to generate a set of .MCS files for a Xilinx XC2V3000
> design, the board uses three XC18V04 PROMs in serial mode, the PROMs
> and the FPGA are on the same chain. I entered the prom config into
> Impact in File Generation mode, but my design is small (bit file is 1.5
> MB in size), so the utility informed me that only one .MCS file is
> actually generated. Now back in JTAG mode, when I initialize the JTAG
> chain, it asks me to associate a file with each device, so I can put in
> the first MCS file into the first PROM,  but what about the others? Can
> I just BYPASS them or do I need to do something else to make this work?
> I'm a bit paranoid about burning up the device, so I didn't want to try
> anything without asking here first. Thanks!
>     -Jim
> 


Yes. Put the generated MCS file into the PROM closest to the FPGA and 
skip the other PROMs. Should work just fine.



-- 
-----------------------------------------------
Johan Bernspćng, xjohbex@xfoix.se
Research engineer

Swedish Defence Research Agency - FOI
Division of Command & Control Systems
Department of Electronic Warfare Systems

www.foi.se

Please remove the x's in the email address if
replying to me personally.
-----------------------------------------------

Article: 86577
Subject: Re: FPGA for video processing
From: =?ISO-8859-15?Q?Benjamin_Menk=FCc?= <benjamin@menkuec.de>
Date: Thu, 30 Jun 2005 14:57:57 +0200
Links: << >>  << T >>  << A >>
Hi Dave,

for the DVI digital Interface, you will need an additional interface 
chip, ie. the TI TFP 401, because the DVI LVDS is a little bit special.
I have built a DVI to LVDS (display-panel) converter, without buffering 
the complete image. It was a little bit tricky to keep the dvi and lcd 
panel synchronized, because I only use a fifo (that can take 4 lines) as 
buffer.

If you want to do image processing, you probably need the entire image 
inside ram, so your ram must be fast enough to write and read an image 
in real-time. A while ago I did this calculation and I figured, that a 
DDR400 will do it for that refresh rate and resolution.

regards,
Benjamin

Article: 86578
Subject: Re: read & write on SDRAM speed with PPC 300 MHz
From: Sean Durkin <smd@despammed.com>
Date: Thu, 30 Jun 2005 15:11:17 +0200
Links: << >>  << T >>  << A >>
Pierre schrieb:
> Hello
> 
> I use a Virtex-II Pro with PowerPC at 300 MHz, 8 kB IOCM, 32 kB DOCM and
> external 32 MB SDRAM (connected on PLB )
> 
>  When I read 10 times 32 MB on my SDRAM, that takes 3.7'' and when I write
> the 320MB on the SDRAM it takes 9.6'' without burst support  and 6" with
> burst support.
> 
> Did someone knows why the read rate is 85 MByte/s and 53 MB/s(maximum ) for
> writing?
For one thing, the PLB runs at 100MHz maximum frequency, even if the
processor runs much faster. So that's one limitation, only a third of
the maximum rate. Another is the data bandwidth on your SDRAM: is it
really 64 bit or only 32bit? On most eval boards it's 16 oder 32bit, so
that's another factor of 2 or 4 less (if it's SDR-DRAM).

Then you have to think about refresh and all that. Even if you do
bursts, the controller has to refresh the memory regularly, so that
takes away even more performance.

Then you have to consider that the PLB is a bus structure. So even if
there's only one component on the bus, there's always a few clock cycles
for bus arbitration when you start a transfer.

Then it depends on your program. For example, if you use a for-loop to
write to and read from every address one after another, then what you
actually do is single 32bit-accesses, meaning that for each
32bit-data-word you read there's bus arbitration, DRAM latency, maybe
you have to wait a few clock cycles because the DRAM is currently
refreshing and so on. This added up maybe gives you as much as 8 clock
cycles (at 100MHz) to read a mere 4 bytes, multiplied by 3 gives you 24
CPU clock cycles (at 300MHz) for one single access, if all goes really
bad, and there you have your ~50MB/s, assuming your RAM is a 32 bits
wide SDR-DRAM.

I don't know how bursts are handled in the DDR-core for the PLB, so I
can't comment on that. But in DDR-SDRAM burst can only be as longs a 8
ticks, then the whole SDRAM-latency-thing starts again.

Neither can I give any useful guesses as to why writing should be slower
than reading, could be some issues with caching.

In cases like this it could also be useful to debug the generated
ELF-file to see how your code maps to assembly instructions.

cu,
Sean

Article: 86579
Subject: Re: PROM Generation question
From: Klaus Falser <kfalser@durst.it>
Date: Thu, 30 Jun 2005 15:14:48 +0200
Links: << >>  << T >>  << A >>
In article <1120134238.598357.287620@g14g2000cwa.googlegroups.com>, 
jimgeorge@gmail.com says...
>     I wanted to generate a set of .MCS files for a Xilinx XC2V3000
> design, the board uses three XC18V04 PROMs in serial mode, the PROMs
> and the FPGA are on the same chain. I entered the prom config into
> Impact in File Generation mode, but my design is small (bit file is 1.5
> MB in size), so the utility informed me that only one .MCS file is
> actually generated. Now back in JTAG mode, when I initialize the JTAG
> chain, it asks me to associate a file with each device, so I can put in
> the first MCS file into the first PROM,  but what about the others? Can
> I just BYPASS them or do I need to do something else to make this work?
> I'm a bit paranoid about burning up the device, so I didn't want to try
> anything without asking here first. Thanks!
>     -Jim
> 
> 
I think you must have made some other mistake.
Having a small design and not using the whole FPGA does not give you a 
smaller configuration file.
If the bit file is for a XC2V3000 then it should hold always the full 
10.494.368 bits and will never fit in a single XC18V04.

You can check this in IMPACT after the PROM generation, where you see in 
the upper part the chain of PROMs and the target with the bit file.
Go with the mouse over the single devices and a yellow window should pop 
up with information about the contained bits and bytes.

Are you shure you did specify a chain of 3 XC18V04 PROMs when generating 
the MCS-files?

Hope this helps
Klaus Falser

Article: 86580
Subject: Re: PROM Generation question
From: "bobrics" <bobrics@gmail.com>
Date: 30 Jun 2005 06:29:20 -0700
Links: << >>  << T >>  << A >>
You should be able to upload bit files to single elements of JTAG
chain. So, yes, you can skip the ones you do not need.

As someone has already mentioned, the file size is a defined number of
bytes for each FGPA type.


Article: 86581
Subject: Re: PROM Generation question
From: Klaus Falser <kfalser@durst.it>
Date: Thu, 30 Jun 2005 15:29:53 +0200
Links: << >>  << T >>  << A >>
In article <MPG.1d2e0eb07a5eff02989690@news.inet.it>, kfalser@durst.it=20
says...
> In article <1120134238.598357.287620@g14g2000cwa.googlegroups.com>,=20
> jimgeorge@gmail.com says...
> >     I wanted to generate a set of .MCS files for a Xilinx XC2V3000
> > design, the board uses three XC18V04 PROMs in serial mode, the PROMs
> > and the FPGA are on the same chain. I entered the prom config into
> > Impact in File Generation mode, but my design is small (bit file is 1.5
> > MB in size), so the utility informed me that only one .MCS file is
> > actually generated. Now back in JTAG mode, when I initialize the JTAG
> > chain, it asks me to associate a file with each device, so I can put in
> > the first MCS file into the first PROM,  but what about the others? Can
> > I just BYPASS them or do I need to do something else to make this work?
> > I'm a bit paranoid about burning up the device, so I didn't want to try
> > anything without asking here first. Thanks!
> >     -Jim
> >=20
> >=20
> I think you must have made some other mistake.
> Having a small design and not using the whole FPGA does not give you a=20
> smaller configuration file.
> If the bit file is for a XC2V3000 then it should hold always the full=20
> 10.494.368 bits and will never fit in a single XC18V04.
>=20
> You can check this in IMPACT after the PROM generation, where you see in=
=20
> the upper part the chain of PROMs and the target with the bit file.
> Go with the mouse over the single devices and a yellow window should pop=
=20
> up with information about the contained bits and bytes.
>=20
> Are you shure you did specify a chain of 3 XC18V04 PROMs when generating=
=20
> the MCS-files?
>=20
> Hope this helps
> Klaus Falser
>=20

Since Johan Bernsp=E5ng said it will work by using only the first PROM I=20
have to add that my experience is limited to Spartan-3, where I have=20
seen always bit-files and MCS-files of the same (full) size.
Should this be different for Virtex-2 I apologize for having given a=20
wrong information.

Best regards
Klaus Falser
 

Article: 86582
Subject: Re: V4 and NBTI question, again..
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 30 Jun 2005 06:36:36 -0700
Links: << >>  << T >>  << A >>
Which makes it a little embarrassing when it catches you out, I guess. ;-)
Syms.
"Austin Lesea" <austin@xilinx.com> wrote in message 
news:d9v22s$1vs1@cliff.xsj.xilinx.com...
> Ray,
>
> Nice thing about and old well known behavior.  It is old, and well known!
>
> Austin
>
> Ray Andraka wrote:
>
>> Austin Lesea wrote:
>>
>>> Marc,
>>>
>>> Contact your FAE for information.
>>>
>>> The information packet on this subject states the shift in Vt is 
>>> reversable.
>>>
>>> Austin
>>
>>
>> As does everything I found in general on NBTI by searching google with 
>> "NBTI"
>> 



Article: 86583
Subject: Re: Clock buffering in VirtexE FPGA
From: "bobrics" <bobrics@gmail.com>
Date: 30 Jun 2005 06:45:05 -0700
Links: << >>  << T >>  << A >>
I assume in your board, push button is tied to some pin on FPGA. In
constraints file (.UCF), specify that   input PORT of your top level
Verilog module, corresponding to your pushbutton SIGNAL, should be
connected to specific input PIN of FPGA.

Example in constraints file
NET "prtPUSH_BUTTON1" LOC = "P17";


You'll have to determine location LOC from board schematics. Sometimes
they'll print it right on surface of the board. Look around pushbutton.


Hope that helps


Article: 86584
Subject: ip core supply
From: "Minimum" <brahms_view@yahoo.it>
Date: 30 Jun 2005 06:52:34 -0700
Links: << >>  << T >>  << A >>
plz touch me more detail if u need the following ip.


brahms_view@yahoo.it
******************************=AD******************************=AD****
1>Ethernet MAC: 10M/100M/1G/10G
2>USB:1.0/2.0/OTG/PHY/software stack
3>JPEG2000
4>PCI/PCI-X/PCI-AHB
5>SATA
6>SDMMC
7>1394 and PHY
8>mp3
9>motion jpeg
10>ARC605 DSP
11>ARM PL110(LCD controller)/PL080(DMA controller)/PL176(Universal
Memory Controller)/PL130 (smartcard)/ARM9/ARM11
12>8051/CAN/Z80/6811/AMBA/PCMC=ADIA/T1E1/IEEE/1284/G711/G726/80=AD86/80186/=
68000

13>MPEG4
14>802.11a/b/g
15>PCI-Express and PHY
******************************=AD******************************=AD****
note:
1> all core are silicon proven and verilog
2> they are not free or exchange.


Article: 86585
Subject: Coverting .mcs file to .bit file
From: "Shai" <shailesh.radhakrishnan@gmail.com>
Date: 30 Jun 2005 06:56:20 -0700
Links: << >>  << T >>  << A >>
Hello,

Is there any way of converting an .mcs file into a bit file....in
Xilinx FPGAs

Any help would be greatly appreciated...

Regards,
- Shailesh


Article: 86586
Subject: Re: ip core supply
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Thu, 30 Jun 2005 07:14:21 -0700
Links: << >>  << T >>  << A >>
Since you admitted last time that they were stolen, why do you
think that anyone would take you up on this offer?

http://groups-beta.google.com/group/comp.arch.fpga/browse_thread/thread/a7d741bf6616c879/2cdbe34225753d86

Ed

Minimum wrote:
> plz touch me more detail if u need the following ip.
> 
> 
> brahms_view@yahoo.it
> ******************************­******************************­****
> 1>Ethernet MAC: 10M/100M/1G/10G
> 2>USB:1.0/2.0/OTG/PHY/software stack
> 3>JPEG2000
> 4>PCI/PCI-X/PCI-AHB
> 5>SATA
> 6>SDMMC
> 7>1394 and PHY
> 8>mp3
> 9>motion jpeg
> 10>ARC605 DSP
> 11>ARM PL110(LCD controller)/PL080(DMA controller)/PL176(Universal
> Memory Controller)/PL130 (smartcard)/ARM9/ARM11
> 12>8051/CAN/Z80/6811/AMBA/PCMC­IA/T1E1/IEEE/1284/G711/G726/80­86/80186/68000
> 
> 13>MPEG4
> 14>802.11a/b/g
> 15>PCI-Express and PHY
> ******************************­******************************­****
> note:
> 1> all core are silicon proven and verilog
> 2> they are not free or exchange.
> 

Article: 86587
Subject: Re: ppc 405 in debug halt mode
From: jagadeesh <reddy.jagadeesh@gmail.com>
Date: Thu, 30 Jun 2005 07:19:11 -0700
Links: << >>  << T >>  << A >>
Hi Peter, Thank you for your great support, now am able to run standalone applications on both PPC's simultaneously and trace the PC.

Now I am trying to run linux on 1 st PPC and standalone program on 2nd ppc. Iam facing one problem, linux booting hangs in middle, the reason I suspect is FIFO collects the instructions adresses , when the full flag is raised ,my module raises DBGC405DEBUGHALT pin to '1' which breaks the processor execution, after collecting FIFO data through 2nd PPC , my logic places DBGC405DEBUGHALT in '0', I found here my 1 st PPC doesn't runs (expected to run Linux)...it just hangs.

I get message processor stopped at adress ....

do I need to take care of something else ...to start and stop processor execution under linux...apart from raising and lowering DBGC405DEBUGHALT signal...?

thanks for your time and consideration,plz do support me to resolve this...

regards Jaggu

Article: 86588
Subject: Re: PROM Generation question
From: =?ISO-8859-15?Q?Johan_Bernsp=E5ng?= <xjohbex@xfoix.se>
Date: Thu, 30 Jun 2005 16:20:53 +0200
Links: << >>  << T >>  << A >>
Klaus Falser wrote:
> Since Johan Bernspćng said it will work by using only the first PROM I 
> have to add that my experience is limited to Spartan-3, where I have 
> seen always bit-files and MCS-files of the same (full) size.
> Should this be different for Virtex-2 I apologize for having given a 
> wrong information.
> 
> Best regards
> Klaus Falser
>  

Well, you are absolutely right about that. The MCS-file should be larger 
than one XC18V04 PROM. I should've thought about that. =)

However, if the board has more PROMs than needed for a specific device 
(which the board I'm using at the moment has) then it is possible to 
program the PROMs the way I mentioned earlier...

Sorry for the confusion..

/Johan



-- 
-----------------------------------------------
Johan Bernspćng, xjohbex@xfoix.se
Research engineer

Swedish Defence Research Agency - FOI
Division of Command & Control Systems
Department of Electronic Warfare Systems

www.foi.se

Please remove the x's in the email address if
replying to me personally.
-----------------------------------------------

Article: 86589
Subject: Re: read & write on SDRAM speed with PPC 300 MHz
From: Mike Harrison <mike@whitewing.co.uk>
Date: Thu, 30 Jun 2005 14:31:33 GMT
Links: << >>  << T >>  << A >>
On Thu, 30 Jun 2005 15:11:17 +0200, Sean Durkin <smd@despammed.com> wrote:

>Pierre schrieb:
>> Hello
>> 
>> I use a Virtex-II Pro with PowerPC at 300 MHz, 8 kB IOCM, 32 kB DOCM and
>> external 32 MB SDRAM (connected on PLB )
>> 
>>  When I read 10 times 32 MB on my SDRAM, that takes 3.7'' and when I write
>> the 320MB on the SDRAM it takes 9.6'' without burst support  and 6" with
>> burst support.
>> 
>> Did someone knows why the read rate is 85 MByte/s and 53 MB/s(maximum ) for
>> writing?

I have no knowledge of this implementation, but common sense should tell you that reads are
inherently slower than writes when both are optimally implemented... 
For a write, you can throw the address & data at the RAM at the same time, and let the RAM and
controller get on with it while you go do something else (other than reading from the same RAM). For
a read, you have to wait until the RAM gives you the data you asked for. 

e.g. in a processor running from a local cache, the write will be happening in parallel with the
fetching of the next instruction(s), but the read must wait for the data to come back from the RAM. 


Article: 86590
Subject: Re: PROM Generation question
From: "jimgeorge at gmail dot com" <jimgeorge@gmail.com>
Date: 30 Jun 2005 07:40:50 -0700
Links: << >>  << T >>  << A >>
OK, thanks all, I found the mistake (this happens because Impact seems
to maintain several "current directory" entries internally, and I was
picking up a bit file for an XC2V1000)

BTW, this is out of curiosity, if I have a board with an FG676
footprint, designed to use either an XC2V3000-FG676 or an
XC2V1000-FG456, and I have three XC18V04 PROMs, what should I do if I
have an XC2V1000-FG456 soldered onto the board? I'm guessing Johan's
suggestion may work then, but correct me if I'm wrong. Thanks!


Article: 86591
Subject: aurora framing
From: "katherine" <weston_katherine@yahoo.co.uk>
Date: 30 Jun 2005 07:50:42 -0700
Links: << >>  << T >>  << A >>
All


Does anyone know whether with aurora framing mode you HAVE to assert
end_of_frame ever (I can see why you might want it but I don't). It
seems that the only point from the aurora cores perspective is that the
data_remainder flags are active.

regards

Katherine


Article: 86592
Subject: Re: Good FPGA for an encryptor
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 30 Jun 2005 08:10:44 -0700
Links: << >>  << T >>  << A >>
Nick,

No one has asked for what you mentioned.  Probably for the reasons you 
mention.

My biggest problem is that whatever we do for security needs to be so 
incredibly well thought through, that adding something in the next 
generation becomes a real issue.  An added feature may bring on a whole 
new set of issues that have to be thought through again!

I am happy that I received a response from a professor to supply a V2 
Pro security pcb.  One by one I will get these boards out there into the 
hands of graduate students looking for fame (if not fortune).

Austin

Article: 86593
Subject: Re: V4 and NBTI question, again..
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 30 Jun 2005 08:17:06 -0700
Links: << >>  << T >>  << A >>
Marc,

The "degradation lock-in" at higher temperatures for NBTI must be 
something that happens beyond 125C.  We do not see any signs of 
irreversable Vt shift.

Then again, how can they tell it isn't hot carrier injection (HCI)?  The 
two causes of Vt shift are similar, but are from different physical 
processes.

Austin

Marc Randolph wrote:

> Ray Andraka wrote:
> 
>>Austin Lesea wrote:
>>
>>
>>>Marc,
>>>
>>>Contact your FAE for information.
>>>
>>>The information packet on this subject states the shift in Vt is
>>>reversable.
>>>
>>>Austin
>>
>>As does everything I found in general on NBTI by searching google with
>>"NBTI"
> 
> 
> Howdy Ray,
> 
> Google had found me a few mentions of it sometimes being irreversable
> under certain conditions - hence the question.  Perhaps I'm
> misunderstanding it, or it doesn't apply to the problem that the V4's
> have.  Here's the best reference:
> 
> http://www.reed-electronics.com/semiconductor/article/CA602829?spacedesc=webex
> 
> Best regards,
> 
>    Marc
> 

Article: 86594
Subject: Re: Xilinx Virtex 4 device technology
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 30 Jun 2005 08:27:40 -0700
Links: << >>  << T >>  << A >>
Amr,

No apology necessary.

Some further notes on SOI (that I can share):

In order to remove or minimize the variation in timing in SOI from the 
floating wells, one needs to add taps.  The addition of the taps to 
every well, results in the area increasing dramatically.  That makes the 
FPGA cost too much, hence the process is not commercially viable.  This 
has been one of the reasons for its non-use.

SOI is also heralded as being more robust for atmospheric neutrons.  But 
it is only twice to five times better than bulk substrates.  A factor of 
two to five is not considered good enough to warrant its use.

SOI also does little to increase the LET for heavy ion strikes, unless 
the design has a lot of taps to collect charge (which adds area again).

Xilinx pioneered a major process development with the introduction of 
triple oxide (now running in two completely different fab lines:  UMC 
and Toshiba).  This allowed us to reduce the leakage current of our 
devices substantially, as well as provide an almost two times better SEU 
  time to upset (over the previous generation technology, or other 90nm 
FPGA competition).

We do consider process techology where it can provide the most benefit. 
  In this case, SOI would increase area, not do anything for leakage, 
and cause all kinds of other problems.  Triple oxide solves a number of 
known problems, by using masks and steps that are standard to the semi 
industry.

Austin

Amr Ahmadain wrote:

> Peter and Austin,
> 
> Again, please do accept my apologies. I asked this question just out of
> curiosity and maybe out of naiveness !!
> 
> Amr
> 

Article: 86595
Subject: Re: Coverting .mcs file to .bit file
From: "John_H" <johnhandwork@mail.com>
Date: Thu, 30 Jun 2005 15:31:47 GMT
Links: << >>  << T >>  << A >>
I've seen people use an mcs2hex utility then a hax2bin.
The Xilinx tools *can* natively produce a .bin file which is the way I've
been doing things since I discovered the option.


"Shai" <shailesh.radhakrishnan@gmail.com> wrote in message
news:1120139780.286445.107720@z14g2000cwz.googlegroups.com...
> Hello,
>
> Is there any way of converting an .mcs file into a bit file....in
> Xilinx FPGAs
>
> Any help would be greatly appreciated...
>
> Regards,
> - Shailesh



Article: 86596
Subject: Re: Coverting .mcs file to .bit file
From: "Andy Peters" <Bassman59a@yahoo.com>
Date: 30 Jun 2005 09:50:18 -0700
Links: << >>  << T >>  << A >>
Shai wrote:
> Hello,
>
> Is there any way of converting an .mcs file into a bit file....in
> Xilinx FPGAs
>
> Any help would be greatly appreciated...

Ummmm, PROMgen?

Ummm, the last step in the ISE GUI? Look under "Generate Programming
File."  The second option is "Generate PROM, ACE or JTAG file."

=a


Article: 86597
Subject: Re: XST: setting top-level generics
From: "Andy Peters" <Bassman59a@yahoo.com>
Date: 30 Jun 2005 10:01:40 -0700
Links: << >>  << T >>  << A >>
Andy Peters wrote:
> I guess this is more of a Xilinx question than a VHDL question.
> Anyways, once again, I find myself wanting to set the value of a
> generic on the top-level of my chip design from the synthesis tool --
> XST, in this case -- either from the GUI or from the command line.
>
> I know I can do this in Precision ...
>
> So what's the magic incantation?
>
> Thanks,
> -a
> (devel (at) latke dot net)

Replying to myself ... I received the following from Xilinx Support:

-----------------------------------------
-----------------------------------------
"*** EMAIL OUT AND STATUS CHANGE 06/30/2005 03:08:55 xud Action Type:
External email
Send to: [External Contact]
Dear Andy Peters,

Thank you for choosing Xilinx Customer Support! My name is Sally Dong
and I will be helping you to resolve your issue. I can be reached via
email at External Contact.

I have tried searching for the XST function of changing generics at
synthesis time and I can not find such one. The XST may not support it.

Please let me know if this did not address your concern, or if you have
any questions on this issue.
-----------------------------------------
-----------------------------------------

So XST doesn't support a language feature that all of the other
synthesis tools (including, BTW, Altera Quartus') support and in most
cases have supports since they started using FPGAs for logic synthesis?

I'm rather amazed that few people use this feature.

Hey, Peter and Austin -- kick someone's ass over at the XST Features
Department.

-a

PS: for my current problem, my solution is to simply create a stupid
little outputs-only entity; each output corresponds to the generic I
wish to set.  If I have two version of my design, I have two different
files, each containing a different version of the entity.  The entity
is given the same name in both files, so when it's used to build the
design, nothing has to change in the main sources,  and my XST script
for each version uses only one of the two files.


Article: 86598
Subject: FPGA development board - urgently
From: "amko" <sinebrate@yahoo.com>
Date: 30 Jun 2005 10:23:37 -0700
Links: << >>  << T >>  << A >>
Does anybody know where I can buy FPGA PC104 development board with
FPGA that have embedded PLL, syncronius 32Megabit (desired organization
32bit x 1M) SRAM device and at least 70 I/O. Instead of SRAM it can be
Dual port RAM (desired organization 32bit x 1M)

Regards, 

Amir


Article: 86599
Subject: Re: synthesis problem
From: "Love Singhal" <lovesinghal@gmail.com>
Date: 30 Jun 2005 10:55:46 -0700
Links: << >>  << T >>  << A >>
I usually get this "Send error report... " error message from bitgen
when there is a write lock on the bit file that I want to write to
(using -w option). After multiple overwrites to the bit file, the bit
file somehow gets a write lock. Choosing a different bit file removes
that error.

-Love




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