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 152250

Article: 152250
Subject: Re: FPGA security, Actel down, now Xilinx too?
From: Tim Wescott <tim@seemywebsite.com>
Date: Wed, 27 Jul 2011 11:11:16 -0500
Links: << >>  << T >>  << A >>
On Wed, 27 Jul 2011 05:17:32 -0700, radarman wrote:

> On Jul 26, 2:04 am, Antti <antti.luk...@googlemail.com> wrote:
>> Hi
>>
>> its maybe not so commonly known that there have been products using
>> Actel secure FPGA's have been cloned already many years ago (readback
>> done by dark engineers at Actel), few month ago a paper was published
>> indicating that ProAsic3 (and other newest Actel FPGA's) have master
>> key that is known not only inside Actel but also for the dark side
>> outside the company. There is at least one known successful Actel
>> ProAsic3 based product cloning done (assumed readback done at Actel
>> fab, not outside).
>>
>> following post has link to documents that show that Xilinx V2/V4/V5 are
>> vulnerable as well.
>>
>> http://it.slashdot.org/story/11/07/21/1753217/FPGA-Bitstream-
Security...
>>
>> P.S. We do not have more info nor the master keys, please do not ask :)
>>
>> Antti Lukatshttp://trioflex.blogspot.com/
> 
> No one should ever assume the device security offered is 100%
> uncrackable. I used to know a guy who did legit "dark engineering" for
> government devices, and it was amazing to hear stories of drilling out
> holes in "secure devices" and extracting data using microscropic probes.
> Another engineer I knew has a collection of IC's embedded in epoxy - the
> company he worked for would shave them layer by layer to extract the
> design physically. (So no, going to an ASIC won't necessarily be 100%
> secure either)
> 
> If man can make it, man can break it.
> 
> The trick is to make it more expensive for the cloners to crack than it
> would be to just license, buy, or reverse engineer another way. Besides,
> a lot of places still send bit streams to China for programming during
> assembly, and at that point, adding bit-stream security is a bit like
> setting the deadbolt on an already open, and empty, barn.

More like shipping all the barn's contents to a pack of known thieves, 
and asking them to please put them back in your barn and lock the door 
behind them when they leave.

> A better metric for FPGA bitstream security, or any security product, is
> the cost per breach and/or time per breach. Assume it can be breached,
> and pick a method where the [cost/time]/[breach] equation works out in
> your favor. BTW - this also means that devices with a master key are
> very bad - because the time/breach is only paid once, and you can rest
> assured, someone besides the manufacturer has it already.
> 
> For an example of this done right, there is an IBM crypto chip that I
> believe is still unbroken - but it has wires around the die that control
> power the SRAM memory holding the crypto keys. If you drill into the
> package, and cut one of the wires, the device loses its memory - and
> becomes a dud. Obviously, you also have to do this work with the chip
> in-system, and running, for the same reason. This is the equivalent of
> the lock on an underground bank vault.
> 
> We will know FPGA vendors are equally serious when the offer a part with
> that level of security. Until then, it's pretty much the equivalent of
> the standard locks on our front doors. Good enough to keep the riff-raff
> out, but not enough to keep the serious thieves away.

Another problem with any high-secure device, whether it be electronic or 
physical, is that the more it protects you from someone else's 
maliciousness, the more it'll harm you when you make an honest mistake.

To extend your bank vault analogy, consider what happens if you lock 
yourself in, or lose the key/combination/whatever.

-- 
www.wescottdesign.com

Article: 152251
Subject: Re: VHDL horror in Xcell 76
From: Kolja Sulimma <ksulimma@googlemail.com>
Date: Wed, 27 Jul 2011 13:50:51 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 27, 11:53=A0am, "RCIngham"
<robert.ingham@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote:
>It should be:
> ...
> sync: process (CLK)
> begin
> =A0 if rising_edge(CLK) then
>...
> end process sync;

actually it should be
sync: process (all)
begin
...
end process;

At least there was VHDL-2008 support announced for ISE11.1...

Kolja

Article: 152252
Subject: Re: VHDL horror in Xcell 76
From: Gabor <gabor@alacron.com>
Date: Wed, 27 Jul 2011 19:00:52 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 27, 5:59=A0am, "RCIngham"
<robert.ingham@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote:
> I should have added that this is also at:http://forums.xilinx.com/t5/Gene=
ral-Technical-Discussion/VHDL-horror-...
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com

Cute article.  If only Xilinx would take some of their own
advice on resets...

Tip #4 - Use active high control signals.  (For some reason
MIG defaults to active low reset).

Where's the tip on running your VHDL through syntax check
before publishing it in a journal?

Cheers,
Gabor

Article: 152253
Subject: image storing into BRAM
From: "balajigec" <balajigec@n_o_s_p_a_m.gmail.com>
Date: Thu, 28 Jul 2011 05:51:56 -0500
Links: << >>  << T >>  << A >>
dear all,
i want to store image from PC to BRAM of an FPGA.i have image 192x96 size.
1) which type of interfacing should i use to transfer image into BRAM from
PC
2) how to write a program for it? do you have any material on this please
tell me.

and i wrote a program for it.it is synthesizer. but how to sending my pixel
values i am not getting. see below my code.

library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;

entity BRAM is
    port (CLK  : in std_logic;
          WE   : in std_logic;
          EN   : in std_logic;
          ADDR : in std_logic_vector(14 downto 0);
          DI   : in std_logic_vector(7 downto 0);
          DO   : out std_logic_vector(7 downto 0));
end BRAM;

architecture syn of BRAM is
    type ram_type is array (18431 downto 0) of std_logic_vector (7 downto
0);
    signal RAM: ram_type;
begin

    process (CLK)
    begin
        if CLK'event and CLK = '1' then
            if EN = '1' then
                if WE = '1' then
                    RAM(conv_integer(ADDR)) <= DI;
                end if;
                DO <= RAM(conv_integer(ADDR)) ;
            end if;
        end if;
    end process;

end syn;

please help me on this..
best regards,
balu  


	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 152254
Subject: Re: Post-map simulation: timing violation and delays
From: "sdaau" <sd@n_o_s_p_a_m.n_o_s_p_a_m.imi.aau.dk>
Date: Thu, 28 Jul 2011 11:36:48 -0500
Links: << >>  << T >>  << A >>
Hi all, 

Just a followup to the previous post, as it seems I got some kind of a
closure:

> So, I decided to study this a bit on a simpler example; ...
>
> http://sdaaubckp.sourceforge.net/post/vhd_counter_aw/
>

I have now uploaded counter_aw2.vhd, test_twb2.vhd and aw2.ucf on the same
location (no changes in previous files). 


First of all, I got a hint at "Buffer_type BUFG ignored? #8"
http://forums.xilinx.com/t5/Implementation/Buffer-type-BUFG-ignored/m-p/167766#M3502
about synthesis of asynchronous vs synchronous reset counter. So I decided
to take a look at the synchronous version from the start (counter_aw2.vhd,
uncommented part). 

Again behavioral sim was I expected it to be, and post-map sim showed X's
and timing violation. Now, the thing is that I wrote the testbench
more-less randomly, just tossing arbitrary signal changes and WAIT delays,
just to see 'in general' how the resulting circuit would behave. So, I had
ended up enforcing 'clk' and 'enable' testbench signals to change at the
*same* moment in time. That may be good enough for behavioral sim, but not
for post-map - and to confirm the previous posts, this is the essence of
the problem. 

So I just inserted a 'WAIT for 1 ns' delay in the testbench
(test_twb2.vhd), and looped the rest of the signals - and there were no
more timing violations in post-map. (noting that if there is no such
explicit loop, the whole process will - loop moving the phase for 1ns each
iteration; and eventually causing the phase between 'enable' and 'clk' to
be again zero, thus causing periodic timing violations). Then I tried
delaying for PERIOD-1ns (just to have the enable rise just before clk) -
and that worked fine as well. 

Now, my guess is that, if I was working with external clk and enable, I
couldn't just delay the signals for as many nanoseconds as I please, just
to avoid timing violations - so I'd have to work according to some spec.
However, in my case, the only thing external signal is the clock, and
enable and reset would be calculated from it - hence there will be some
inherent delay between clk and enable; and that would further limit the
usage of the counter. While talking of 'limitations': expanding the data
out in bit lines and zooming in (in isim) will reveal that the glitches are
due to different propagation times of individual bit changes (so they occur
only between particular value transitions) - so, in fact, nothing strange
there (as I first thought) :) 

Measuring (in isim) the time between the clk posedge and change of data
(cout) will reveal about 5.5 ns delay. Just for the heck of it, I tried to
limit that with a timing constraint in the .ucf file: 

   ...
   TIMEGRP "couts" OFFSET = OUT 4 ns AFTER COMP "clk";

.. and immediately after, post-map static analysis failed:

--  Timing constraint: TIMEGRP "couts" OFFSET = OUT 4 ns AFTER COMP "clk";

--   16 paths analyzed, 16 endpoints analyzed, 16 failing endpoints 
--   16 timing errors detected. 
--   Minimum allowable offset is   5.878ns. 

So, I guess this tells me: if I sample the cout 6 ns after clk posedge, I
should have safe cout data; so for the testbench clock @50Hz, I could
initiate count at clk posedge, and consider to have the right data @ next
negedge, 10 ns after. However, even with a separate process: 

    process(clk)
    begin
      if falling_edge(clk) then
      cout <= std_logic_vector(pre_count); 
      end if; 
    end process;

.. glitches will still be there in post-map. And I guess, even if
'buffered' one more time, they will still occur: my guess is, synthesizer
would instantiate FF for the bit buffer anyways, so there will be still
different length routes to them -> different delays -> glitch. So the min
6ns wait would be needed in respect to 'when does the rest of the engine
read this data' (rather than, 'when to read for a buffer' to avoid seeing
glitches altogether). 


In the end, even if I could somehow mask the glitches and avoid seeing
them, metastability is still inherent
(http://www.asic-world.com/tidbits/metastablity.html) in reality; so I
guess this is as good as it gets in post-map sim (given that my testbench
is 'arbitrarily written'; and the only constraint I have in the aw2.ucf is
clock @100 MHz). 

And, of course: getting rid of the X's and timing violations in post-map
sim, doesn't mean that post-route sim will be just as well behaving :) But
at least I have some sort of understanding from a simple example to go
along with, when tackling that - thank you all for the help!

Cheers!
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 152255
Subject: Bitstream compression
From: Rob Gaddi <rgaddi@technologyhighland.com>
Date: Thu, 28 Jul 2011 16:47:44 -0700
Links: << >>  << T >>  << A >>
Hey all--

So my experience with the native bitstream compression algorithms 
provided by the FPGA vendors has been that they don't actually achieve 
all that much compression.  This makes sense given that the expansion 
has to be accomplished in the FPGA hardware, and so can't be all that 
aggressive.

I generally find myself programming FPGAs from microcontrollers, and so 
I've got clock cycles and RAM to throw at the problem to try to do 
better.  We've had some limited luck implementing really stupid RLE, 
just compressing the runs of 0x00 and 0xFF and calling it a day.  But I 
was wondering whether anyone's found a better, more universal approach.

The ideal would be a compression/expansion library with fairly good 
compression ratios, where the expansion side could operate without 
malloc and on-the-fly on a stream of data rather than requiring large 
buffers.  The compression side could use phenominal amounts of compute 
power and RAM, since it would be happening on the PC.  But the goal 
would be able to decompress on something like an LPC1754 (32kB RAM total).

Anyone have any thoughts?

-- 
Rob Gaddi, Highland Technology
Email address is currently out of order

Article: 152256
Subject: Re: Bitstream compression
From: Vladimir Vassilevsky <nospam@nowhere.com>
Date: Thu, 28 Jul 2011 19:15:46 -0500
Links: << >>  << T >>  << A >>


Rob Gaddi wrote:

> Hey all--
> 
> So my experience with the native bitstream compression algorithms 
> provided by the FPGA vendors has been that they don't actually achieve 
> all that much compression.

> The ideal would be a compression/expansion library with fairly good 
> compression ratios, where the expansion side could operate without 
> malloc and on-the-fly on a stream of data rather than requiring large 
> buffers.

It won't be generally possible to beat vendor provided basic compression 
more then by a factor of ~1.5 or so. The gain of 1.5 times wouldn't 
really improve anything.

> The compression side could use phenominal amounts of compute 
> power and RAM, since it would be happening on the PC.  But the goal 
> would be able to decompress on something like an LPC1754 (32kB RAM total).
> 
> Anyone have any thoughts?

Just try 7zip on the FPGA binaries and see for yourself.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

Article: 152257
Subject: Re: Bitstream compression
From: Rob Gaddi <rgaddi@technologyhighland.com>
Date: Thu, 28 Jul 2011 17:40:25 -0700
Links: << >>  << T >>  << A >>
On 7/28/2011 5:15 PM, Vladimir Vassilevsky wrote:
>
>
> Rob Gaddi wrote:
>
>> Hey all--
>>
>> So my experience with the native bitstream compression algorithms
>> provided by the FPGA vendors has been that they don't actually achieve
>> all that much compression.
>
>> The ideal would be a compression/expansion library with fairly good
>> compression ratios, where the expansion side could operate without
>> malloc and on-the-fly on a stream of data rather than requiring large
>> buffers.
>
> It won't be generally possible to beat vendor provided basic compression
> more then by a factor of ~1.5 or so. The gain of 1.5 times wouldn't
> really improve anything.
>
>> The compression side could use phenominal amounts of compute power and
>> RAM, since it would be happening on the PC. But the goal would be able
>> to decompress on something like an LPC1754 (32kB RAM total).
>>
>> Anyone have any thoughts?
>
> Just try 7zip on the FPGA binaries and see for yourself.
>
>
> Vladimir Vassilevsky
> DSP and Mixed Signal Design Consultant
> http://www.abvolt.com

Just did, on an FPGA with an admittedly small fill ratio.  The 
uncompressed bitstream for an XC3S200 is 1,047,616 bits.  Using Xilinx 
bitstream compression gets it down to 814,336 bits, or about 100kB. 
7-Zip knocked it down to 16kB.

Another design uses a decent about of an XC6S45.  Native size is 
11,875,104 bits (~1.5MB).  Bitstream compresson gives me 1.35MB.  7-Zip 
gives me 395kB.

I've got a project coming up around an Altera Arria II, with 30Mb of 
configuration.  If I could get a 3:1, 4:1 compression ratio it would be 
a pretty radical savings on flash size.

-- 
Rob Gaddi, Highland Technology
Email address is currently out of order

Article: 152258
Subject: Re: Bitstream compression
From: "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk>
Date: Fri, 29 Jul 2011 03:20:48 -0500
Links: << >>  << T >>  << A >>
I cant really see why you are trying to do this. If its just for fun then
great, but flash isn't that expensive and you are only talking about 30Mb
not 30Gb.

Jon 	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 152259
Subject: Re: Bitstream compression
From: Mike Perkins <spam@spam.com>
Date: Fri, 29 Jul 2011 10:22:38 +0100
Links: << >>  << T >>  << A >>
On 29/07/2011 09:20, maxascent wrote:
> I cant really see why you are trying to do this. If its just for fun then
> great, but flash isn't that expensive and you are only talking about 30Mb
> not 30Gb.
>
> Jon 	
> 					
> ---------------------------------------		
> Posted through http://www.FPGARelated.com

Many embedded processors have a limited amount of Flash memory, so it 
would be an advantage to efficiently compress a bitstream to save a 
component and IO.

-- 
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

Article: 152260
Subject: Re: Bitstream compression
From: Allan Herriman <allanherriman@hotmail.com>
Date: Fri, 29 Jul 2011 10:43:24 GMT
Links: << >>  << T >>  << A >>
On Thu, 28 Jul 2011 17:40:25 -0700, Rob Gaddi wrote:

> On 7/28/2011 5:15 PM, Vladimir Vassilevsky wrote:
>>
>>
>> Rob Gaddi wrote:
>>
>>> Hey all--
>>>
>>> So my experience with the native bitstream compression algorithms
>>> provided by the FPGA vendors has been that they don't actually achieve
>>> all that much compression.
>>
>>> The ideal would be a compression/expansion library with fairly good
>>> compression ratios, where the expansion side could operate without
>>> malloc and on-the-fly on a stream of data rather than requiring large
>>> buffers.
>>
>> It won't be generally possible to beat vendor provided basic
>> compression more then by a factor of ~1.5 or so. The gain of 1.5 times
>> wouldn't really improve anything.
>>
>>> The compression side could use phenominal amounts of compute power and
>>> RAM, since it would be happening on the PC. But the goal would be able
>>> to decompress on something like an LPC1754 (32kB RAM total).
>>>
>>> Anyone have any thoughts?
>>
>> Just try 7zip on the FPGA binaries and see for yourself.
>>
>>
>> Vladimir Vassilevsky DSP and Mixed Signal Design Consultant
>> http://www.abvolt.com
> 
> Just did, on an FPGA with an admittedly small fill ratio.  The
> uncompressed bitstream for an XC3S200 is 1,047,616 bits.  Using Xilinx
> bitstream compression gets it down to 814,336 bits, or about 100kB.
> 7-Zip knocked it down to 16kB.
> 
> Another design uses a decent about of an XC6S45.  Native size is
> 11,875,104 bits (~1.5MB).  Bitstream compresson gives me 1.35MB.  7-Zip
> gives me 395kB.
> 
> I've got a project coming up around an Altera Arria II, with 30Mb of
> configuration.  If I could get a 3:1, 4:1 compression ratio it would be
> a pretty radical savings on flash size.


A design done for a client, using Virtex 6, with gzip -9 for 
compression.  Figures are from memory and are approximate.

Uncompressed: 7.5MBytes
compressed: a few 10s of kB (empty FPGA)
compressed: 500kBytes (mostly empty FPGA)
compressed: 2MBytes (mostly full FPGA)
compressed: 7.5MBytes (with bitstream encryption)

Note: there's no point using compression with encryption, as the 
encrypted images don't compress.

I used gzip as the decompresser is open source and fairly "light".

The Xilinx built-in compression doesn't do a good job because it merely 
joins identical frames.  The chance of getting identical frames is low 
for any design that uses a reasonable amount of the fabric.  (If you're 
not using most of the fabric, you could be using a smaller, cheaper 
device.)
OTOH, if you are using bitstream encryption, the built-in compression is 
the only compression you can use and it will be better than nothing.

Regards,
Allan

Article: 152261
Subject: Re: Bitstream compression
From: Thomas Entner <thomas.entner99@gmail.com>
Date: Fri, 29 Jul 2011 04:43:11 -0700 (PDT)
Links: << >>  << T >>  << A >>
From my memory, Altera has a much better "native" compression than
Xilinx, with typical compression-ratios of about 50%.

Regards,

Thomas

www.entner-electronics.com

Article: 152262
Subject: Re: Bitstream compression
From: "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk>
Date: Fri, 29 Jul 2011 07:25:32 -0500
Links: << >>  << T >>  << A >>
>On 29/07/2011 09:20, maxascent wrote:
>> I cant really see why you are trying to do this. If its just for fun
then
>> great, but flash isn't that expensive and you are only talking about
30Mb
>> not 30Gb.
>>
>> Jon 	
>> 					
>> ---------------------------------------		
>> Posted through http://www.FPGARelated.com
>
>Many embedded processors have a limited amount of Flash memory, so it 
>would be an advantage to efficiently compress a bitstream to save a 
>component and IO.
>
>-- 
>Mike Perkins
>Video Solutions Ltd
>www.videosolutions.ltd.uk
>

Well you can get serial flash devices that use a small amount of IO and
have large capacities. I dont think you would use the internal flash of a
processor to store a bitstream unless it was very small. I just cant see
the point of going to all the trouble to do this unless you could shrink
the bitstream to almost nothing. 

Jon	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 152263
Subject: Re: Bitstream compression
From: Jason <cincydsp@gmail.com>
Date: Fri, 29 Jul 2011 06:29:52 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 28, 8:40=A0pm, Rob Gaddi <rga...@technologyhighland.com> wrote:
> On 7/28/2011 5:15 PM, Vladimir Vassilevsky wrote:
>
>
>
>
>
>
>
>
>
>
>
> > Rob Gaddi wrote:
>
> >> Hey all--
>
> >> So my experience with the native bitstream compression algorithms
> >> provided by the FPGA vendors has been that they don't actually achieve
> >> all that much compression.
>
> >> The ideal would be a compression/expansion library with fairly good
> >> compression ratios, where the expansion side could operate without
> >> malloc and on-the-fly on a stream of data rather than requiring large
> >> buffers.
>
> > It won't be generally possible to beat vendor provided basic compressio=
n
> > more then by a factor of ~1.5 or so. The gain of 1.5 times wouldn't
> > really improve anything.
>
> >> The compression side could use phenominal amounts of compute power and
> >> RAM, since it would be happening on the PC. But the goal would be able
> >> to decompress on something like an LPC1754 (32kB RAM total).
>
> >> Anyone have any thoughts?
>
> > Just try 7zip on the FPGA binaries and see for yourself.
>
> > Vladimir Vassilevsky
> > DSP and Mixed Signal Design Consultant
> >http://www.abvolt.com
>
> Just did, on an FPGA with an admittedly small fill ratio. =A0The
> uncompressed bitstream for an XC3S200 is 1,047,616 bits. =A0Using Xilinx
> bitstream compression gets it down to 814,336 bits, or about 100kB.
> 7-Zip knocked it down to 16kB.
>
> Another design uses a decent about of an XC6S45. =A0Native size is
> 11,875,104 bits (~1.5MB). =A0Bitstream compresson gives me 1.35MB. =A07-Z=
ip
> gives me 395kB.
>
> I've got a project coming up around an Altera Arria II, with 30Mb of
> configuration. =A0If I could get a 3:1, 4:1 compression ratio it would be
> a pretty radical savings on flash size.
>
> --
> Rob Gaddi, Highland Technology
> Email address is currently out of order

The algorithm that 7-Zip uses internally for .7z file compression is
LZMA:

http://en.wikipedia.org/wiki/Lzma

One characteristic of LZMA is that its decoder is much simpler than
the encoder, making it well-suited for your application. You would be
most interested in the open-source LZMA SDK:

http://www.7-zip.org/sdk.html

They provide an ANSI C implementation of a decoder that you can port
to your platform. Also, there is a reference application for an
encoder (I believe also written in C). I have used this in the past to
compress firmware for embedded systems with good success. I use the
encoder as a post-build step to compress the firmware image into an
LZMA stream (note that the compression is not done with 7-Zip, as the .
7z format is a full-blown archive; the reference encoder just gives
you a stream of compressed data, which is what you want). The
resulting file is then decompressed on the embedded target at firmware
update time. The decoder source code is most amenable to porting to 32-
bit architectures; I have implemented it on the LPC2138 ARM7 device
(with the same 32 KB of RAM as your part) as well as a few AVR32UC3
parts.

A couple other things: I originally did this ~4 years ago with a much
older version of the SDK; it's possible that things have changed since
then, but it should still be worth a look. LZMA provides good
compression ratios with a decoder that in my experience runs well on
embedded platforms. Secondly, you do have to be careful with the
parameters you use at the encoder if you want to bound the amount of
memory required at the decoder. More specifically, you need to be
careful which "dictionary size" you use for the encoder. As you might
expect, a larger dictionary gives you better compression ratios, but
the target running the decoder will require at least that much memory
(e.g. an 8 KB dictionary size will require at least 8 KB of memory for
the decoder).

Jason

Article: 152264
Subject: Re: Bitstream compression
From: nico@puntnl.niks (Nico Coesel)
Date: Fri, 29 Jul 2011 13:51:54 GMT
Links: << >>  << T >>  << A >>
Rob Gaddi <rgaddi@technologyhighland.com> wrote:

>Hey all--
>
>So my experience with the native bitstream compression algorithms 
>provided by the FPGA vendors has been that they don't actually achieve 
>all that much compression.  This makes sense given that the expansion 
>has to be accomplished in the FPGA hardware, and so can't be all that 
>aggressive.
>
>I generally find myself programming FPGAs from microcontrollers, and so 
>I've got clock cycles and RAM to throw at the problem to try to do 
>better.  We've had some limited luck implementing really stupid RLE, 
>just compressing the runs of 0x00 and 0xFF and calling it a day.  But I 
>was wondering whether anyone's found a better, more universal approach.

The problem is that Hufman based algorithms don't gain that much. I
recall someone has had lots of succes using an RLE like scheme on
nibbles (4 bit) instead of whole bytes.

Look here:
http://www.sulimma.de/prak/ws0001/projekte/ralph/Projekt/index.htm
-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

Article: 152265
Subject: DVI-decoder clock question
From: Mawa_fugo <ccon67@netscape.net>
Date: Fri, 29 Jul 2011 06:59:46 -0700 (PDT)
Links: << >>  << T >>  << A >>
Let say I have two DVI streams - generated by two encoders, those have
different video contents but same pixel clock

The two tmds streams travel thru cables then - are decoded by two
decoders - then fed into an FPGA

The question is how the two clocks at the output of the encoders look
like, are they the same? Can we use only one clock for both channel to
clock the data in the FPGA?

========

My theory is that, the original clock goes to two 10x then divided
back 1/10, so they are supposedly be in same phase... or what
else ???



Article: 152266
Subject: Re: Bitstream compression
From: Vladimir Vassilevsky <nospam@nowhere.com>
Date: Fri, 29 Jul 2011 09:21:45 -0500
Links: << >>  << T >>  << A >>


Rob Gaddi wrote:

> On 7/28/2011 5:15 PM, Vladimir Vassilevsky wrote:
>> Rob Gaddi wrote:
>>
>>> So my experience with the native bitstream compression algorithms
>>> provided by the FPGA vendors has been that they don't actually achieve
>>> all that much compression.
>>
>> It won't be generally possible to beat vendor provided basic compression
>> more then by a factor of ~1.5 or so. The gain of 1.5 times wouldn't
>> really improve anything.
>>
> Native size is 
> 11,875,104 bits (~1.5MB).  Bitstream compresson gives me 1.35MB.  7-Zip 
> gives me 395kB.

Interesting.

I tried to compress JBCs from heavily used Altera Cyclone, got only 
about x1.5 of compression.

As for compression algorithm, something like a bit oriented LZSS or LZW 
would be easy to implement. The decompression part is trivial. If you 
don't care about speed, the compression part is very simple, too. I 
don't know if the further sophistication of the algorithm would do much 
of a difference.

Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

Article: 152267
Subject: Re: Bitstream compression
From: Noob <root@127.0.0.1>
Date: Fri, 29 Jul 2011 16:36:48 +0200
Links: << >>  << T >>  << A >>
[ NB: I've added comp.compression to the mix ]

Jason wrote:

> Rob Gaddi wrote:
> 
>> Just did, on an FPGA with an admittedly small fill ratio.  The
>> uncompressed bitstream for an XC3S200 is 1,047,616 bits.  Using Xilinx
>> bitstream compression gets it down to 814,336 bits, or about 100kB.
>> 7-Zip knocked it down to 16kB.
>>
>> Another design uses a decent about of an XC6S45.  Native size is
>> 11,875,104 bits (~1.5MB).  Bitstream compresson gives me 1.35MB.  7-Zip
>> gives me 395kB.
>>
>> I've got a project coming up around an Altera Arria II, with 30Mb of
>> configuration.  If I could get a 3:1, 4:1 compression ratio it would be
>> a pretty radical savings on flash size.
> 
> The algorithm that 7-Zip uses internally for .7z file compression is
> LZMA:
> 
> http://en.wikipedia.org/wiki/Lzma
> 
> One characteristic of LZMA is that its decoder is much simpler than
> the encoder, making it well-suited for your application. You would be
> most interested in the open-source LZMA SDK:
> 
> http://www.7-zip.org/sdk.html
> 
> They provide an ANSI C implementation of a decoder that you can port
> to your platform. Also, there is a reference application for an
> encoder (I believe also written in C). I have used this in the past to
> compress firmware for embedded systems with good success. I use the
> encoder as a post-build step to compress the firmware image into an
> LZMA stream (note that the compression is not done with 7-Zip, as the .
> 7z format is a full-blown archive; the reference encoder just gives
> you a stream of compressed data, which is what you want). The
> resulting file is then decompressed on the embedded target at firmware
> update time. The decoder source code is most amenable to porting to 32-
> bit architectures; I have implemented it on the LPC2138 ARM7 device
> (with the same 32 KB of RAM as your part) as well as a few AVR32UC3
> parts.
> 
> A couple other things: I originally did this ~4 years ago with a much
> older version of the SDK; it's possible that things have changed since
> then, but it should still be worth a look. LZMA provides good
> compression ratios with a decoder that in my experience runs well on
> embedded platforms. Secondly, you do have to be careful with the
> parameters you use at the encoder if you want to bound the amount of
> memory required at the decoder. More specifically, you need to be
> careful which "dictionary size" you use for the encoder. As you might
> expect, a larger dictionary gives you better compression ratios, but
> the target running the decoder will require at least that much memory
> (e.g. an 8 KB dictionary size will require at least 8 KB of memory for
> the decoder).

Lempel-Ziv-Oberhumer (LZO) might also be worth investigating.

http://en.wikipedia.org/wiki/Lempel–Ziv–Oberhumer

The LZO library implements a number of algorithms with the
following characteristics:
* Compression is comparable in speed to deflate compression.
* Very fast decompression
* Requires an additional buffer during compression (of size 8 kB or 64 kB, depending on compression level).
* Requires no additional memory for decompression other than the source and destination buffers.
* Allows the user to adjust the balance between compression quality and compression speed, without affecting the speed of decompression.

Regards.

Article: 152268
Subject: die's in different packages
From: Sharan <sharan.basappa@gmail.com>
Date: Fri, 29 Jul 2011 09:14:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
can someone tell me if there is any differences in the die for the
following 2 devices in virtex-7

XC7VX415TFFG1158 and XC7VX415TFFG1927

Both these devices are listed as having same logic resources.
XC7VX415TFFG1158 has 35 X 35 mm package
XC7VX415TFFG1927 has 45 X 45 mm package

Can I assume that the only difference is the package and the
underlying die is going to be the same?

TIA

Article: 152269
Subject: Re: die's in different packages
From: Gabor <gabor@szakacs.invalid>
Date: Fri, 29 Jul 2011 18:15:31 -0400
Links: << >>  << T >>  << A >>
Sharan wrote:
> can someone tell me if there is any differences in the die for the
> following 2 devices in virtex-7
> 
> XC7VX415TFFG1158 and XC7VX415TFFG1927
> 
> Both these devices are listed as having same logic resources.
> XC7VX415TFFG1158 has 35 X 35 mm package
> XC7VX415TFFG1927 has 45 X 45 mm package
> 
> Can I assume that the only difference is the package and the
> underlying die is going to be the same?
> 
> TIA

I'm not in the V7 camp yet, but to date that is the way
Xilinx handles chip products.  For each family and gate
size there is one die, which has different bond-outs
depending on the package.  If it's a small die in a
large package you end up with non-connected package pins.
A large part in a small package ends up with unbonded
IOB's.  But open the parts in the FPGA editor and you
see the exact same diagram with just different labels
on the IOB's.  In fact on the smaller packages you
can use the unbonded IOB's as extra resources if you
run out of fabric flops for example.

-- Gabor

Article: 152270
Subject: Re: Bitstream compression
From: OutputLogic <evgenist@gmail.com>
Date: Fri, 29 Jul 2011 17:42:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
Not all applications necessarily configure FPGAs from flash. Many apps
do it over the network, including initial configuration and subsequent
partial reconfigurations. So it's beneficial to have a good bitstream
compression scheme to reduce the amount of traffic.

Thanks,
Evgeni
http://outputlogic.com

Article: 152271
Subject: Pipeline stages of the Multiplier core (ISE Coregen)
From: "spman" <spman_xm@n_o_s_p_a_m.yahoo.com>
Date: Mon, 01 Aug 2011 09:09:40 -0500
Links: << >>  << T >>  << A >>
Hello friends

I can't understand how the Pipeline stages affect the multiplier core?
I tested 1 stage and 4 stages. The result is given with 1 clock for 1
stage, and 4 clocks for 4 stages.
When i decrease the clock frequency, no difference is happened.
But as i increase the clock frequency for 4 stages,the result is given with
5 clocks! why?

what is benefits of 4 stages in comparison to 1 stage?

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 152272
Subject: Re: die's in different packages
From: "sharanbr" <sharanb@n_o_s_p_a_m.hcl.com>
Date: Mon, 01 Aug 2011 09:09:51 -0500
Links: << >>  << T >>  << A >>
>Sharan wrote:
>> can someone tell me if there is any differences in the die for the
>> following 2 devices in virtex-7
>> 
>> XC7VX415TFFG1158 and XC7VX415TFFG1927
>> 
>> Both these devices are listed as having same logic resources.
>> XC7VX415TFFG1158 has 35 X 35 mm package
>> XC7VX415TFFG1927 has 45 X 45 mm package
>> 
>> Can I assume that the only difference is the package and the
>> underlying die is going to be the same?
>> 
>> TIA
>
>I'm not in the V7 camp yet, but to date that is the way
>Xilinx handles chip products.  For each family and gate
>size there is one die, which has different bond-outs
>depending on the package.  If it's a small die in a
>large package you end up with non-connected package pins.
>A large part in a small package ends up with unbonded
>IOB's.  But open the parts in the FPGA editor and you
>see the exact same diagram with just different labels
>on the IOB's.  In fact on the smaller packages you
>can use the unbonded IOB's as extra resources if you
>run out of fabric flops for example.
>
>-- Gabor
>

Thanks, Gabor.

Also, can you tell why certain devices are in a specific package while
another device with more supported pins is in a smaller package.

For example (example only, nothing specific to Virtex-7)
v7vx1140t - min package is 45 x 45 mm package & supports 480 pins
v7vx585T  - min package is 35 x 35 mm package & supports 600 pins

I am not sure why a 480 pin needs 45X45 mm package while 600 pins is put in
a 35X35 mm package


	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 152273
Subject: Re: Pipeline stages of the Multiplier core (ISE Coregen)
From: "RCIngham" <robert.ingham@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Mon, 01 Aug 2011 10:14:35 -0500
Links: << >>  << T >>  << A >>
Generally, more pipeline stages means higher maximum operating clock
stages. This is because of reduced delay due to logic + routing between
banks of registers.

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 152274
Subject: Re: die's in different packages
From: "RCIngham" <robert.ingham@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Mon, 01 Aug 2011 10:16:45 -0500
Links: << >>  << T >>  << A >>
>>Sharan wrote:
>>> can someone tell me if there is any differences in the die for the
>>> following 2 devices in virtex-7
>>> 
>>> XC7VX415TFFG1158 and XC7VX415TFFG1927
>>> 
>>> Both these devices are listed as having same logic resources.
>>> XC7VX415TFFG1158 has 35 X 35 mm package
>>> XC7VX415TFFG1927 has 45 X 45 mm package
>>> 
>>> Can I assume that the only difference is the package and the
>>> underlying die is going to be the same?
>>> 
>>> TIA
>>
>>I'm not in the V7 camp yet, but to date that is the way
>>Xilinx handles chip products.  For each family and gate
>>size there is one die, which has different bond-outs
>>depending on the package.  If it's a small die in a
>>large package you end up with non-connected package pins.
>>A large part in a small package ends up with unbonded
>>IOB's.  But open the parts in the FPGA editor and you
>>see the exact same diagram with just different labels
>>on the IOB's.  In fact on the smaller packages you
>>can use the unbonded IOB's as extra resources if you
>>run out of fabric flops for example.
>>
>>-- Gabor
>>
>
>Thanks, Gabor.
>
>Also, can you tell why certain devices are in a specific package while
>another device with more supported pins is in a smaller package.
>
>For example (example only, nothing specific to Virtex-7)
>v7vx1140t - min package is 45 x 45 mm package & supports 480 pins
>v7vx585T  - min package is 35 x 35 mm package & supports 600 pins
>
>I am not sure why a 480 pin needs 45X45 mm package while 600 pins is put
in
>a 35X35 mm package

Look at the inter-ball dimensions on the different packages.
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com



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