Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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
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. HenkArticle: 70527
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
> ... 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
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
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, pravArticle: 70531
> >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
"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'indirizzoArticle: 70533
"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
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
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.nlArticle: 70536
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. JohnArticle: 70537
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.nlArticle: 70538
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"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, > pravArticle: 70540
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> Have a look at the SAVE NET FLAG constraint in the cgd.pdf documentation. http://toolbox.xilinx.com/docsan/xilinx5/pdf/docs/cgd/cgd.pdfArticle: 70542
"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.nlArticle: 70543
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! FrankArticle: 70544
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. -jgArticle: 70545
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 KapoorArticle: 70546
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). ThomasArticle: 70547
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: 70548Yes, 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, > > JakeArticle: 70549
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:
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