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 70525

Article: 70525
Subject: Re: TCP/IP in Virtex II Pro
From: Matthew Ouellette <matt.ouellette@xilinx.comNOSPAM>
Date: Fri, 18 Jun 2004 13:42:11 -0600
Links: << >>  << T >>  << A >>
The EMAC core is delivered by Xilinx in the EDK is identical to the 
pay-for core, except it has an eval license that enables reset circuitry 
so that the device times out after 8-10 hours of use.  Besides the reset 
logic, the functionality should be equivalent.

Matt

qianeasy wrote:
> Hi,David
>     Did you use the EMAC core in EDK, I heard that it will be unstable
> unless you buy a core from Xilinx.  
> 

Article: 70526
Subject: Re: Is there a verilog version of PicoBlaze?
From: henk@mediatronix.com (Henk van Kampen)
Date: 18 Jun 2004 14:33:28 -0700
Links: << >>  << T >>  << A >>
Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in message news:<f8f5d09c1bhectj9dm3qtv1e771tnug1j7@4ax.com>...
> This doesn't help the OP though, as the core itself is written in
> VHDL.  Steve, would there be any problem if a third party (e.g. me)
> were to publish a behavioural Verilog description of picoblaze[123]?

Allan:
The Picoblaze cores are, although VHDL, just instantiations of LUTS
and FF's. So a straight translation should be possible.
Henk

Article: 70527
Subject: Re: C Header files for User Design Logic in the Nios.
From: etd606@hotmail.com (Ted)
Date: 18 Jun 2004 14:58:49 -0700
Links: << >>  << T >>  << A >>
Hello,

A more direct question, for the above VHDL code, how do I access the
write_data port in C i.e. in cmd mode? I tried changing the contents
of the base address of the VHDL blackbox but the else condition ALWAYS
occurs. In my excalibur.h file, I get the blackbox base address as
0x00020020. No end address is specified.

Is it required to have a register file? Must I include the
byte_enable, reset signals to get it to work? When I do something like
i=*point1, then it goes into the else condition. Probably something to
do with exception handling.

Is it a problem with the VHDL coding (Checked seperately in ModelSim)
or something to do with the C?

Perplexed...

Article: 70528
Subject: Re: Linux on Xilinx v2pro: OCM access?
From: Peter Monta <pmonta@www.pmonta.com>
Date: Fri, 18 Jun 2004 21:58:53 GMT
Links: << >>  << T >>  << A >>
> ... Please note that the OCM is virtually addressed

Thank you *very much*.  It works perfectly now.

I imagine the MMU is on the PLB-facing side of the PPC,
so that address translation is not active for cache-like
entities like OCM.  But I would not have guessed this
without help.

Xilinx hotline support is pretty reasonable, but
Usenet can sometimes outperform it :-).

Cheers,
Peter Monta
RGB Networks, Inc.

Article: 70529
Subject: Re: compressing Xilinx bitstreams
From: Neil Glenn Jacobson <n.e.i.l.j.a.c.o.b.s.o.n@x.i.l.i.n.x.c.o.m>
Date: Fri, 18 Jun 2004 15:25:39 -0700
Links: << >>  << T >>  << A >>
While this doesn't exactly answer your question, the new Xilinx XCFP 
serial PROMs support storage of compressed bitstream data.  The data is 
compressed when you translate to the PROM format and the PROM does the 
decompression before delivery to the FPGA.

http://www.xilinx.com/bvdocs/publications/ds123.pdf



John Larkin wrote:

>Forgive me if this has been asked before, but does anybody have
>comments or links to simple methods of compressing/decompressing
>Xilinx configuration bitstreams? I've been perusing a few of my .rbt
>files, and they have long bunches of 1s and 0s (interestingly,
>different designs seem to have more 1s, others mostly 0s.) I'd think
>that something very simple might achieve pretty serious (as, maybe
>2:1-ish) compression without a lot of runtime complexity. We generally
>run a uP from EPROM, with the uP code and the packed Xilinx config
>stuff in the same eprom, with the uP bit-banging the Xilinx FPGA at
>powerup time. So a simple decompressor would be nice.
>
>I did google for this... haven't found much.
>
>Thanks,
>
>John
>
>  
>


Article: 70530
Subject: scatter gather DMA in OPB MAC core
From: praveenkn123@yahoo.com (prav)
Date: 18 Jun 2004 21:45:02 -0700
Links: << >>  << T >>  << A >>
Hi all,

I wanted to know how scatter gather DMA is different from normal DMA
operations.scatter gather DMA  concept is used in OPB ethernet core.
I am not getting any good resources on this .Suggesting any good links
on scatter gather DMA would be appreciated.

rgds,
prav

Article: 70531
Subject: Re: compressing Xilinx bitstreams, some test data
From: "Antonio Pasini" <NOSPAM_pasini.a@tin.it>
Date: Sat, 19 Jun 2004 07:04:19 GMT
Links: << >>  << T >>  << A >>
> >Forgive me if this has been asked before, but does anybody have
> >comments or links to simple methods of compressing/decompressing
> >Xilinx configuration bitstreams? I've been perusing a few of my .rbt

My application uses a 128Kb flash micro (M16C) to program a SpartanIIE-100
in slave parallel mode. Back "then", external serial config. memory price
was outrageusly high. Besides, by keeping all inside the main micro, I now
can remote upgrade my FPGA code very very easily.

To free some more Kb for a new requirement, I compressed the bit-stream with
a simple LZW implementation, and decompressed
on the fly before sending to FPGA.

Here are some results from a real design.

Starting from uncompressed design BIN file:
CAMERA.BIN:   107980  bytes
LZW compression with different "dictionary table" bit length:

BIT   SIZE
10    73853
11    63283
12    61442
13   58012
14   56803

Same design, but BIN file has been compressed by ISE:

CAMERA_COMP.BIN 97944    (what I was using before; leaved 30 Kb for my app.
code)
After LZW compression:

BIT   SIZE
10    73475
11    65442
12    62865
13    58795
14    57687

As expected, you get slightly better results starting from uncompressed BIN
stream, when using simple compression algorithms.

Even after adding code decompression, I saved tens of flash Kb to implement
more features at no cost.
Initial configuration has slowed down, of course: before I was pumping out
data to FPGA as fast as possible with string move assembly instructions.
Now I have to decompress on the fly.
Times stays in the hundreds of ms range, tough.

RAM USAGE during decompression:

from bit width of string table, you define the table size this way (smaller
prime number larger than 2^bits):

BITS        TABLE SIZE
14            18041
13            9029
12            5021
11            2053
<= 10        1031

During decompression, you will need   3*TABLE_SIZE bytes + a decode buffer;
decode buffer size can be in the 2000-4000 bytes range.
Yes, it's big. But...given that FPGA programming is the first thing I do at
startup, I can use up to all the M16C RAM available; after FPGA programming,
all that ram is available again for my code.
Even much less, with some checks during compression.


I used a slightly modified version of the code for LZW compression published
by Mark. Nelson on DDJ, Oct. 89.
Google found a copy of the article here:
http://www.dogma.net/markn/articles/lzw/lzw.htm


Please, post your results if you tested for have different implementations!







Article: 70532
Subject: Re: CPLD mistery. Help.
From: 7+5@supereva.it (Fabio G.)
Date: Sat, 19 Jun 2004 11:58:29 GMT
Links: << >>  << T >>  << A >>
"lc" <cupido@REMOVEmail.ua.pt> ha scritto:

>This is crazy !
>Anyone has a clue about what is happening ?

Maybe it's an electrical problem in your board

--
Per rispondermi via email sostituisci il risultato
dell'operazione (in lettere) dall'indirizzo

Article: 70533
Subject: Re: compressing Xilinx bitstreams
From: "roller" <trash_nospam@hotmail.com>
Date: Sat, 19 Jun 2004 15:55:47 +0200
Links: << >>  << T >>  << A >>

"John Larkin" <jjlarkin@highSNIPlandTHIStechPLEASEnology.com> escribió en el
mensaje news:hh34d0tud78se5vqejirkc2bvufbd8io3d@4ax.com...
>
> Forgive me if this has been asked before, but does anybody have
> comments or links to simple methods of compressing/decompressing
> Xilinx configuration bitstreams? I've been perusing a few of my .rbt
> files, and they have long bunches of 1s and 0s (interestingly,
> different designs seem to have more 1s, others mostly 0s.) I'd think
> that something very simple might achieve pretty serious (as, maybe
> 2:1-ish) compression without a lot of runtime complexity. We generally
> run a uP from EPROM, with the uP code and the packed Xilinx config
> stuff in the same eprom, with the uP bit-banging the Xilinx FPGA at
> powerup time. So a simple decompressor would be nice.
>
> I did google for this... haven't found much.
>

try searching for RLE (run length encoding) that's the encoding used for
.PCX graphic files

> Thanks,
>
> John
>



Article: 70534
Subject: Re: >Math Skills = >Engineer ?
From: "Victor Schutte" <victors@mweb.co.za>
Date: Sat, 19 Jun 2004 17:14:58 +0200
Links: << >>  << T >>  << A >>
Better understanding of engineering (and the world)  develops better math
skills.

If you understand your problem then the mathematics will fall into place. If
you don't understand the problem the mathematics will seem pointless.

I only really started understanding some of my school math after I applied
it in the practical field.

Low math skills/marks = low understanding of applications/problems.

Victor

<user@domain.invalid> wrote in message
news:w8tzc.540$XFF1.47@news04.bloor.is.net.cable.rogers.com...
> Does better math skills really equal a better engineer in the future?
>



Article: 70535
Subject: Re: compressing Xilinx bitstreams
From: nico@puntnl.niks (Nico Coesel)
Date: Sat, 19 Jun 2004 15:27:40 GMT
Links: << >>  << T >>  << A >>
John Larkin <jjlarkin@highSNIPlandTHIStechPLEASEnology.com> wrote:

>
>Forgive me if this has been asked before, but does anybody have
>comments or links to simple methods of compressing/decompressing
>Xilinx configuration bitstreams? I've been perusing a few of my .rbt
>files, and they have long bunches of 1s and 0s (interestingly,
>different designs seem to have more 1s, others mostly 0s.) I'd think
>that something very simple might achieve pretty serious (as, maybe
>2:1-ish) compression without a lot of runtime complexity. We generally
>run a uP from EPROM, with the uP code and the packed Xilinx config
>stuff in the same eprom, with the uP bit-banging the Xilinx FPGA at
>powerup time. So a simple decompressor would be nice.
>
>I did google for this... haven't found much.

Tried it but found the files aren't reduced in size much and more
important, the software required to decompress the file eats away all
the savings for a 400k device. In other words: Unless you have more
than around half a million gates of configuration data, it's not worth
it.

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Article: 70536
Subject: Re: compressing Xilinx bitstreams
From: John Larkin <jjlarkin@highlandSNIPtechTHISnologyPLEASE.com>
Date: Sat, 19 Jun 2004 09:08:16 -0700
Links: << >>  << T >>  << A >>
On Sat, 19 Jun 2004 15:27:40 GMT, nico@puntnl.niks (Nico Coesel)
wrote:

>John Larkin <jjlarkin@highSNIPlandTHIStechPLEASEnology.com> wrote:
>
>>
>>Forgive me if this has been asked before, but does anybody have
>>comments or links to simple methods of compressing/decompressing
>>Xilinx configuration bitstreams? I've been perusing a few of my .rbt
>>files, and they have long bunches of 1s and 0s (interestingly,
>>different designs seem to have more 1s, others mostly 0s.) I'd think
>>that something very simple might achieve pretty serious (as, maybe
>>2:1-ish) compression without a lot of runtime complexity. We generally
>>run a uP from EPROM, with the uP code and the packed Xilinx config
>>stuff in the same eprom, with the uP bit-banging the Xilinx FPGA at
>>powerup time. So a simple decompressor would be nice.
>>
>>I did google for this... haven't found much.
>
>Tried it but found the files aren't reduced in size much and more
>important, the software required to decompress the file eats away all
>the savings for a 400k device. In other words: Unless you have more
>than around half a million gates of configuration data, it's not worth
>it.


OK, bear with me on this. Here's a piece of a .rbt for a Spartan XL...

01111111111111111111111111111111111111111111111111111111111011111111111111111111111111110111111110111111011111111110111111110101011101111110111111011111111111111111110011111111111111111111111111111111111111111111111111111110101
01111111111111111111111111111111111111111111111111111111111111111111111111111101111111111111111111111111110111111101111111111111111110111111111111110111111111111011111101111111111111111111111111111111111111111111111111111110011
01111111111111111111111111111111111111111111111111111100011111111111111111101111111100111111110011111111111111011101111111111100111011110011111011111111111111111111111110110111001111111111111111111111110111111011111111111111011
01111111111111111111111111111111111111111111111111111111011111111111111111101111111101011111111110011111111111111100111111111111011111111101111111111111111111110111101111111111110111111111111111111111111111111111111111111111110
01111111111111111111111111111111111111111111110111111111111111111111111111111111111111111111111011111111111111111011010111111110011111111011111111111011111011111011110101111111000111111111011111111111101111111111111110101101111
00111111111111111111111111111111111111111111000111111111111111111111111111111111111111111111111111111111110111111111110110111111011111111111111111111101111111111111111101111111110111111100011111111111111111111111111101101100000
01111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111110111111111101110111101011111111111111111111111111111111111111101111111101111111111111111111111111111111111111110111111100
00011111111111111111111111111111111111111111111111111111111100111111011111111111001111110110101111001111111101111111111111001111111100111111111001111101101011110110011111101010111101111111111111111111111010111100111111111111000
01101011111111111111111111111111111111111111111111111111111110101111111111111111101011111110011110111111110101001110111111101011011100111111111010010111001111110110101101111111111111111111111111111111110011111101111111010100111
01111011111111111111111111111111111111111111111111111111111111111111011111111111111111110111111111111111110110111111111111101011011111111111111111111101111111111111111101111111111101111111111111111111111111111111111111011111010
01101111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111110011111111111111111111111111111111111111111001111111111111111110111111111111111111111111111111111111111111111111100111110011000
01111111111111111111111111111111111111111111111111111111111011111111101111111110111111111011111111101111011110111111111110111101111001101111101111111110101011111011010111101111111110111111101111111111111111111110111111110100011
01101111111111111111111111111111111111111111111011111111111111111111111111111111111111111111111111111111111101011010111111111111110111101111111111111101011011111111111111011110111111111111111111111111111111111111111111111110101
00111100111111111111111111111111111111111111111011111111110100111111100011111101001111111000111111111111111110101011111101101011110010011111011011111111101011110110101111010001111110111111111111111111111111111101111100111110111


Where there are lots of 1's. Other hunks of this file are almost all
1's. So what we need is a not-very-general compression scheme, with
the only "dictionary" entry being "the following is a hunk of 1's". So
the decompressor could be very simple.

Interestingly, this is for a Spartan 2:

00000000000001001000000000000000
00000000000000000000000000000000
00000000000100100000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000001001000000000000000
00000000000000000000000000000000
00000000000100100100000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000001001100000000000000
00000000000000000000000000000000
11111111000100110000000100000100
00000000010001000000000000010000
00000000000001110100100000000000
11010100000000000011010000000000
00000001000000000000000000001000
00111111110001000000000000000000

Which has long runs of zeroes!

Just eyeballing these files, it looks like something very simple could
get at least a 2:1 squash factor.

John


Article: 70537
Subject: Re: compressing Xilinx bitstreams
From: nico@puntnl.niks (Nico Coesel)
Date: Sat, 19 Jun 2004 17:51:15 GMT
Links: << >>  << T >>  << A >>
John Larkin <jjlarkin@highlandSNIPtechTHISnologyPLEASE.com> wrote:

>On Sat, 19 Jun 2004 15:27:40 GMT, nico@puntnl.niks (Nico Coesel)
>wrote:
>
>>John Larkin <jjlarkin@highSNIPlandTHIStechPLEASEnology.com> wrote:
>>
>>>
>>>Forgive me if this has been asked before, but does anybody have
>>>comments or links to simple methods of compressing/decompressing
>>>Xilinx configuration bitstreams? I've been perusing a few of my .rbt
>>>files, and they have long bunches of 1s and 0s (interestingly,
>>>different designs seem to have more 1s, others mostly 0s.) I'd think
>>>that something very simple might achieve pretty serious (as, maybe
>>>2:1-ish) compression without a lot of runtime complexity. We generally
>>>run a uP from EPROM, with the uP code and the packed Xilinx config
>>>stuff in the same eprom, with the uP bit-banging the Xilinx FPGA at
>>>powerup time. So a simple decompressor would be nice.
>>>
>>>I did google for this... haven't found much.
>>
>>Tried it but found the files aren't reduced in size much and more
>>important, the software required to decompress the file eats away all
>>the savings for a 400k device. In other words: Unless you have more
>>than around half a million gates of configuration data, it's not worth
>>it.
>
>
>OK, bear with me on this. Here's a piece of a .rbt for a Spartan XL...
>
>00111111110001000000000000000000
>
>Which has long runs of zeroes!
>
>Just eyeballing these files, it looks like something very simple could
>get at least a 2:1 squash factor.

Did you ever try to compress these files? I totally agree with you
that these files _look_ easy to compress, but they aren't. I tried
RLE, but that will only save 5% to 10%. ZIP does a little better. I
just tried to compress a .bit file for a 400k gate Xilinx device and
it reduces the size by 26% but you'll need to have room for the ZIP
decompression code...

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Article: 70538
Subject: Re: compressing Xilinx bitstreams
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Sat, 19 Jun 2004 20:33:04 +0100
Links: << >>  << T >>  << A >>
Nico Coesel wrote:

> Did you ever try to compress these files? I totally agree with you
> that these files _look_ easy to compress, but they aren't.

But with a little knowledge of the structure maybe we can do
better than blind RLE or whatever.  Surely any structure
which the eye can see can be efficiently encoded?

e.g. "There will be lots of repeats for unused LUTs.
      These are coded as abc and should be decoded as xyz"



Article: 70539
Subject: Re: scatter gather DMA in OPB MAC core
From: "Stan Lackey" <stanlackey@hotmail.com>
Date: Sat, 19 Jun 2004 15:44:15 -0400
Links: << >>  << T >>  << A >>
"Normal" DMA architectures define packet buffers with addresses that
increment, that is, the set of buffers might occupy memory addresses
10000-1FFFF for a 64K-byte queue.  This has the advantage that it's easy to
implement, however it is inflexible, since each queue has a fixed size you
set up at boot time (probably at design time, actually.)  If you only have a
few queues, or lots of memory, this is probably OK.

With "scatter-gather" architecture, on the other hand, each buffer might
have a link to another buffer, or there might be an array (map) of addresses
of buffers.  You don't get from one buffer to the next by incrementing the
address, you get there by following a pointer.  This plan is better if you
need lots of queues and they all don't have to be max size simultaneously.
Scatter-gather lets you dynamically allocate memory to a queue on-demand,
and make better use of memory.

-Stan

"prav" <praveenkn123@yahoo.com> wrote in message
news:863df22b.0406182045.5fd5693b@posting.google.com...
> Hi all,
>
> I wanted to know how scatter gather DMA is different from normal DMA
> operations.scatter gather DMA  concept is used in OPB ethernet core.
> I am not getting any good resources on this .Suggesting any good links
> on scatter gather DMA would be appreciated.
>
> rgds,
> prav



Article: 70540
Subject: Re: compressing Xilinx bitstreams, some test data
From: Frank Benoit <nospam@xyz.com>
Date: Sat, 19 Jun 2004 21:45:28 +0200
Links: << >>  << T >>  << A >>

I used something similar with a Spartan2-50, MC9S12dp256 (Star12 Motorola
256kb Flash).

1. rbt -> bin-file
2. compress with LZ77
3. split it in blocks with max 16kb (because of star12 banking)
4. convert to C-Sources
	const unsigned char data_00[]={
		.........
	};
5. compile it into the Star12 application 
6. on startup of Star12 whole RAM is used for decompression. program fpga
over jtag
7. startup of µC application code

But sorry, I have no good Information about the ratio. In the beginning I
used an XC2S200 which image was definitly too big and the design was
nearly empty (ratio 25%). Now i use the XC2S50 and the design is using
98% of the fpga. But the only thing I know, the compressed image uses
max. 3 banks, so ratio between 45-68% of original size.

Frank

Article: 70541
Subject: Re: Xilinx XST synthesis removes input pin even though it's LOCed
From: Frank Benoit <nospam@xyz.com>
Date: Sat, 19 Jun 2004 22:15:14 +0200
Links: << >>  << T >>  << A >>

> Have a look at the SAVE NET FLAG constraint in the cgd.pdf documentation.

http://toolbox.xilinx.com/docsan/xilinx5/pdf/docs/cgd/cgd.pdf



Article: 70542
Subject: Re: compressing Xilinx bitstreams
From: nico@puntnl.niks (Nico Coesel)
Date: Sat, 19 Jun 2004 23:23:57 GMT
Links: << >>  << T >>  << A >>
"Tim" <tim@rockylogic.com.nooospam.com> wrote:

>Nico Coesel wrote:
>
>> Did you ever try to compress these files? I totally agree with you
>> that these files _look_ easy to compress, but they aren't.
>
>But with a little knowledge of the structure maybe we can do
>better than blind RLE or whatever.  Surely any structure
>which the eye can see can be efficiently encoded?

Another poster claims huge space savings by using a special tool. I
haven't looked into it.

>e.g. "There will be lots of repeats for unused LUTs.
>      These are coded as abc and should be decoded as xyz"

That's the problem: the routing software smears the entire design over
the entire FPGA if it can. You can specify to leave unused space from
the bit-file, but you'll see the length varies with every routing run.
Perhaps the best space saver is to constrain the router to use only a
part of the FPGA which just is big enough to contain your design. Next
specify to leave out the unused stuff.

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Article: 70543
Subject: Newbie: Spartan XCS10
From: "\(beta-\) Frank Nitzsche" <beta-frank@beta-x.de>
Date: Sun, 20 Jun 2004 01:30:31 +0200
Links: << >>  << T >>  << A >>
Hello @all,

at power-up, are all registers (for counters) initialized with known state
(e.g. zeros)?

Because the interface to a MC looks like a SRAM and there is no need for
reset. Moreover on the FPGA is not another unused pin for reset-input
available. All processes would be well syncronized forever, if they starts
with zeros. Internal timebase delivers a quarz-oszillator.

I hope, this text is sufficient understandable;-) Thanks!

Frank



Article: 70544
Subject: Re: CPLD mistery. Help.
From: Jim Granville <no.spam@designtools.co.nz>
Date: Sun, 20 Jun 2004 12:15:23 +1200
Links: << >>  << T >>  << A >>
lc wrote:
> Hello,
> 
> I implemented in a CPLD a very simple 8bit output port
> The CPLD connects to the microcontroller bus and this part
> is simply a latch that is controlled by the address bus and /wr
> signal. Couldn't be simpler.
> 
> I had a 'testpoint' out of the CPLD just to check when this latch
> is gated.
> 
> All works fine.
> 
> When I sad to myself that I no longer need the testpoint, and removed
> the VHDL line, the port stopped to work !!!
> I changed nothing else !!!!
> Put back the test point and the port worked again !!!
> 
> This is crazy !
> Anyone has a clue about what is happening ?
> Help is appreciated, I may leave the testpoint there
> but I want to understand what is going on !

All fitters create a report file, showing what resource is mapped:
create the two versions of this report file, and compare them.
That should indicate what is happening.
-jg


Article: 70545
Subject: Re: CPLD mistery. Help.
From: a1kapoor@yahoo.com (Ashish Kapoor)
Date: 19 Jun 2004 19:07:21 -0700
Links: << >>  << T >>  << A >>
Hi,

CPLDs don't have a latches. Synthesis tools implement these
by using combinational cycles. These work for simple cases.
For more complex cases timing problems may cause the latches
behave incorrectly. Such problems are very hard to debug.
Looking at your design it certainly falls in the complex
category. You have two latches interacting with each other.

I would recommend you try to convert your design to a synchronous
circuit. If that is not possible you might have to tweak the
RTL or constraints to get around the problem. Try using
"syn_keep" on the latch gate signals.


Cheers,

Ashish Kapoor

Article: 70546
Subject: Re: compressing Xilinx bitstreams
From: Zak <jute@zak.invalid>
Date: Sun, 20 Jun 2004 13:52:58 +0200
Links: << >>  << T >>  << A >>
Nico Coesel wrote:

> Did you ever try to compress these files? I totally agree with you
> that these files _look_ easy to compress, but they aren't. I tried
> RLE, but that will only save 5% to 10%.

Probably because the looks for repeating bytes, while here we have only 
repeating stretches of 0's. What might work is to re-code the file into 
numbers giving the number of 0 bits between 1's as a first step:

00100000101000000000010000011000000000001 would turn into
2 - 5 - 1 - 10 - 5 - 0 - 11.

  Stretches of 0 more than 254 long could be encoded as 255, meaning 255 
zeroes and no 1, whith the next number to give more 0's. 1-[255 0s]-1 
would code to 255 0 in that case.

The resulting bytes are probably easier to huffman compress. Or it may 
pay to do this for 0 runs up to 16 long, and coding these as bytes with 
values 0-15 (not as nibble pairs, subsequent nibbles probably do not 
have any relationship).


Thomas

Article: 70547
Subject: Altera Quartus II on Linux
From: Miika Pekkarinen <miika.nospam1@ihme.org>
Date: Sun, 20 Jun 2004 20:04:59 +0300
Links: << >>  << T >>  << A >>
Hello,

I have Altera Quartus II 4.0 software and I managed to successfully install
it on a Debian Linux machine (with Intel Pentium 4 processor). However,
always when I try to start the software, I will get the following messages:

        "Choose the preferred look and feel for the Quartus II software..."

I select Quartus II and click OK. After that I will get:

        "MainWin license not available -- to run the Quartus II software, you
         must specify a valid license file that contains a MainWin license."

I have searched Altera web sites and newsgroups but was unable to find out
what is this MainWin license. So does anybody know what it is, where could
I get one and how to specify the license file for Quartus?

Thanks for your advice. It would be nice if I could do finally all FPGA
development on Linux.
-- 
Miika Pekkarinen <miipekk@it.jyu.fi>,
Department of Math. Information Technology,
University of Jyvaskyla, P.O. Box 35, FIN-40014 Jyvaskyla, FINLAND




Article: 70548
Subject: Re: IOBs in NGC - problem with OBUFT
From: jakespambox@yahoo.com (Jake Janovetz)
Date: 20 Jun 2004 10:29:32 -0700
Links: << >>  << T >>  << A >>
Yes, but there are some pins that I needed to add iobufs on, so this
isn't an option.  XST applies that parameter to all i/os, and you
cannot apply selectively.

I ended up having to write a wrapper for my module.  The wrapper
contains the I/Os and requires synthesis, but the underlying block
does not.

   Jake


"Brannon King" <bking@starbridgesystems.com> wrote in message news:<cav27m$svb@dispatch.concentric.net>...
> In XST use the -iobuf NO parameter to turn off the automatic buffer
> insertion.
> 
> 
> "Jake Janovetz" <jakespambox@yahoo.com> wrote in message
> news:d6ad3144.0406171545.68f3e376@posting.google.com...
> > (I'm not sure why, but Google apparently loses about 50% of my posts,
> > so I'll try this again)
> >
> > I have a few modules that I would provide to customers.  They are all
> > quite simple, but by not providing Veriog/VHDL I shelter them from the
> > implementation details and possible warnings that would come from
> > synthesis.  So, I'd prefer to provide library "objects" in NGC format.
> >
> > Most of the modules are 'internal' (not requiring IOBs), but one needs
> > to map to IO pins, including an 8-bit bidirectional bus.  If I -don't-
> > include IOBs in the module, the parent design synthesizes OBUFs for
> > the bidir bus and completely ignores the inputs.  If I manually map
> > the OBUFTs within the module, I get complaints during parent synthesis
> > because apparently the parent is adding OBUFs which compete with the
> > OBUFTs in the module.
> >
> > I'd prefer a solution which requires as little 'extra' work on the
> > parent side of things, but would appreciate any suggestions.
> >
> >    Cheers,
> >    Jake

Article: 70549
Subject: Is the Xilinix XC3020 atill supported?
From: drwho8@att.net (Gregg C Levine)
Date: Sun, 20 Jun 2004 17:45:27 GMT
Links: << >>  << T >>  << A >>
Hello from Gregg C Levine
I have here an XC3020, and matching configuration storage EEPROM, an 
XC1736DPC, the were originally purchased for another project. We ended up not 
doing that project. Now we'd like to use both for something completely different. 
Are these parts still supported by Xilinix? Has anyone heard differently? We'd also 
prefer to do the programming under Linux.
Gregg C Levine drwho8 atsign att dot net




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