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
Systolic array architectures are commonly used for image/video compression hardware blocks (e.g. convolution filters, motion estimation, etc). I loosely have an idea that this is because they are efficient at reusing the data, and thus reduce memory accesses in comparsion to say a custom designed high throughput singular processing element. Would this be generally considered the princicpal benefit and are there other benefits? I have read that they are considered "i/o bandwidth efficient", I guess thats just another way of saying what I've just outlined above? Is there ever scenario's where the area and switching overhead of a systolic array would warrant a less bandwidth efficient, more serial approach - or is that just plain ridulous to consider? For example could you hope to trade less switching in the datapath for increased switching in the memory accesses but still make an overall reduction in switching? Looking forward to any comments/flames/rants :-)Article: 90101
>
> . cout
> . _|_
> . ,--/___\ CYMUX
> . | | |
> . ______ | | |
> . a(b) ---------| | | | | ____ XORCY
> . b(n) ------x--| LUT4 |-x----------\\ \_____
> . pt_n ---x--|--| | | x----//___/
> . sel ---|--|--|______| | |
> . | | / |
> . | | __ / |
> . | '------| \ _/ cin
> . '---------|__/
> . MULT_AND
I wanted something similar but could not get the
synthesis tool to generate the circuit, so I instantiated
my own.. here it is, you can change the INIT values of the
LUT to get what you want.
-----------------------------------------------------------
-- MUX_ADD_VECTOR - when ADD = '1' add O = A + B else O = C
-----------------------------------------------------------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
library UNISIM;
use UNISIM.vcomponents.all;
entity MUX_ADD_VECTOR is
generic (WIDTH : integer := 32;
SLICE : integer := 1);
port (A : in std_logic_vector (WIDTH-1 downto 0);
B : in std_logic_vector (WIDTH-1 downto 0);
C : in std_logic_vector (WIDTH-1 downto 0);
ADD : in std_logic;
O : out std_logic_vector (WIDTH-1 downto 0));
end MUX_ADD_VECTOR;
architecture XILINX_virtex of MUX_ADD_VECTOR is
component LUT4_L
generic(INIT : bit_vector);
port (LO : out STD_ULOGIC;
I0 : in STD_ULOGIC; I1 : in STD_ULOGIC;
I2 : in STD_ULOGIC; I3 : in STD_ULOGIC);
end component;
component MUXCY_L
port(LO : out STD_ULOGIC; CI : in STD_ULOGIC;
DI : in STD_ULOGIC; S : in STD_ULOGIC);
end component;
component XORCY
port(O : out STD_ULOGIC;
CI : in STD_ULOGIC; LI : in STD_ULOGIC);
end component;
component MULT_AND
port(LO : out STD_ULOGIC;
I0 : in STD_ULOGIC; I1 : in STD_ULOGIC);
end component;
-------------------------------------------------------
-- Input mapping for LUTs
-------------------------------------------------------
-- I0 -> A (i)
-- I1 -> ADD
-- I2 -> B(i)
-- I3 -> C(i)
-- LO -> otemp(i)
-------------------------------------------------------
-- C(i) B(i) ADD A(i) LO -> Output
-------------------------------------------------------
-- X 0 1 0 INIT[2,A] -> 0
-- X 0 1 1 INIT[3,B] -> 1
-- X 1 1 0 INIT[6,E] -> 1
-- X 1 1 1 INIT[7,F] -> 0
-- 0 X 0 X INIT[0,1,4,5] -> 0
-- 1 X 0 X INIT[8,9,C,D] -> 1
--------------------------------------------------------------
-- INIT F E D C - B A 9 8 - 7 6 5 4 - 3 2 1 0
-- 0 1 1 1 1 0 1 1 0 1 0 0 1 0 0 0 -->
X"7B48"
--------------------------------------------------------------
signal otemp : std_logic_vector (WIDTH-1 downto 0);
signal mando : std_logic_vector (WIDTH-1 downto 0);
signal carry : std_logic_vector (WIDTH downto 0);
attribute BEL : string;
begin -- XILINX_virtex
carry(0) <= '0';
mux_add: for i in 0 to WIDTH-1 generate
constant row : integer := (WIDTH/2) - i/2 - 1;
attribute INIT of mux_add_lut4_inst : label is "7B48";
begin
mux_add_lut4_inst : LUT4_L
generic map (INIT => X"7B48")
port map (I0 => A(i), I1 => ADD,
I2 => B(i), I3 => C(i),
LO => otemp(i));
mux_add_mand_inst : MULT_AND
port map (I0 => A(i), I1 => ADD, LO => mando(i));
mux_add_mxcy_inst : MUXCY_L
port map (DI => mando(i), CI => carry(i),
S => otemp(i), LO => carry(i+1));
mux_add_xorc_inst : XORCY
port map (CI => carry(i), LI => otemp(i), O => O(i));
end generate mux_add;
end XILINX_virtex;
Quark....
Article: 90102Adam, The "stuck at fault" testing is extremely high: we carefully examine test patterns for their IC design shcematic coverage. Even the generic FPGA flow test coverage is much better than an ASIC. Austin > Er, really? I thought you had to pay extra for the 100% tested ones. > Does Xilinx really test every net on every chip for (say) stuck-at > faults before shipping? > > - a >Article: 90103
Ben, -snip- > > > So, can I then summarize that EasyPath is basically a standard Virtex II/4 > but with less time on the testbed (only the cells and routing used by the > customer are tested) in order to reduce cost? There is a basic 1's, 0's, shorts, leakage, etc test done to all parts, EasyPath or no. And then, for EasyPath, only those features used by the customer are tested (with the addition of any LUT pattern for the CLBs they use, and any IO strength for th IOB standard they use, which allows for the two most common ECO requests we got after we shipped). The difference in test time between as close as we can get to 100% testing for any possible use, and as close as we can get to 100% testing for one use is SIGNIFICANT. As well, the test yield to one test program is also SIGNIFICANTLY HIGHER than for many thousands of test programs (which is potentially what it takes to have an acceptable AQL). Better Yield + Shorter Time = Lower Cost to Xilinx, which means Lower Prices to customer. AustinArticle: 90104
Hello! I have a system implemented in hardware and I prototyped it in VIrtex-II Pro platform with a testbench. I analyzed the signals using chipscope and it worked the same as in simulation. After this, I created a project in EDK and substituted the testbench by a Microblaze processor. The project stopped working. Now, I need to debug the harwdare in order to find the problem, ut I don't know how to do this. I'm trying to use ModelSim. In fact, I generated the simulation files and created the testbench file to stimulate my system. However, this testbench just generates the clock and reset, so I need instanciate my software in order to generate the other stimulus. Is it possible? What do I have to do in order to incorporate my software in simulation? Does anyone can help me? Thank you! MelissaArticle: 90105
Ben - Although I haven't used Xilinx' EasyPath product, it makes a fair amount of sense. I've used V2Pro parts for a while, but I don't care about or use the PowerPC processor I get in the the part. EasyPath would let me get cheaper parts in volume for 2 reasons - a) Xilinx doesn't even have to test the PPC core in parts they would ship to me. They save dollars because of chip test time saving. b) Xilinx could send me parts with dead PPC cores since I don't use that feature. I assume the PPC core takes a reasonable amount of silicon area, so it would have a reasonable chance of having a defect. Those 'dead' chips are currently lost revenue to Xilinx, the incremental cost to sell them to me is fairly low. I don't know how the EasyPath cost compares to the Altera HardCopy2, but it sure makes sense that EasyPath could offer nice savings for the volume user and additional profit for Xilinx. A win-win situation. John ProvidenzaArticle: 90106
Peter - A few comments: - You can run your design at only 24 MHz? And you have an extra 3ns? Luxury! - A circuit may fail only once every billion years, but the failure will always occur when the customer is present. - You can forget about metastability, but metastability will never forget about you. Take care, Bob Perlman Cambrian Design Works On 4 Oct 2005 13:21:55 -0700, "Peter Alfke" <peter@xilinx.com> wrote: >"Metastability" is a popular word to scare inexperienced designers. > >If you run a 1.8 MHz clock (even with a similar asynchronous data >rate), your chance of having a 3 ns extra metastable delay is once per >billion years (at 24 MHz it would be only 5 million years). >For every additional ns of acceptable settling time, the >mean-time-between-failure increases at least a million times. (see >XAPP094 on the Xilinx website) >The probability of your flip-flop failing during the life of this >universe (even if you do nothing) with more than 10 ns of >unaccounted-for delay is so minute it is practically zero. >There are more important things to worry about, forget metastability... >Peter Alfke, Xilinx Applications (who actually has created quantitative >data about metastability)Article: 90107
Thank you for your interest. I want to get the result on each 80 ns. (pipeline can be used.) Sorry but since I have worked with xilinx devices several years, I have no experience about MicroBlaze. So could you plz recommend some materials about MicroBlaze?Article: 90108
Austin Lesea <austin@xilinx.com> writes: > Better Yield + Shorter Time = Lower Cost to Xilinx, which means Lower > Prices to customer. I'm assuming it's mostly "better yield", though, right? I mean, Atmel's chips can 100% test themselves (they'll even give you the bitstream that does it), and I'd bet that the XC6200 could've (or probably even did). Isn't the test time just a matter of "assembly line latency" rather than "assembly line throughput"? It shouldn't be like an ASIC where you need a separate, active device to test it and those devices are in short supply. Forgive me if this sounds stupid. My knowledge gets pretty fuzzy down at the fabrication/process level. - a -- PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380Article: 90109
Hello,
I have a board with 256M of RAM and a V2P30. Designed a simple system
in EDK with the RAM partitioned into 2 equal parts. Compiled a .elf to
live in one half and want to use the other half for a filesystem. The
.elf runs fine in the sense that I get the "Usage: " message from it
via the UART when it realizes it doesn't have any input files. I have
trouble when I try and incorporate the filesystem. I am using xilmfs
so I generated a .mfs with a couple dummy files in it. Now if I use
XMD to first download the elf, it works fine (as described above -- I
can run it over and over again) but when I download the .mfs, it
ceases to work ('run' produces nothing via stdout -- I think it is
spinning somewhere in a few lines of code). I am careful about the
address supplied to the 'dow' command and am using the -data flag. A
wierd effect of the .mfs download is that the pc is reset to 0x0000cfd4
instead of to 0xfffffffc when I type 'run' at XMD prompt. Trying to
set the pc manually doesn't help ('rwr' then 'con'). I get the feeling
that the .elf is getting stomped by the .mfs even though it really
doesn't know anything about that region of memory (I am pretty sure I
got the linker script right).
I could easily babble quite a bit more about this, but will leave it
here. If any further info would help you help me, let me know! I
appreciate any advice...
Joey
Article: 90110Ed McGettigan wrote: > With every board that is designed you have to make some trade offs > between peripherals, performance, power and cost. The ML401/2/3 > boards are loaded with features at a very reasonable price point > and in order to do that we had to make some compromises in certain > areas. Indeed these boards are a great value and far cheaper than what it would cost me to build something similar, which is not common for development kits. Thank you for your explanation. I hadn't notice the 15 bit per pixel llimitation of the ML403. I am still deciding if it is worth doing the extra VGA board - an alternative is to reduce the vertical refresh to 56 Hz or something like that. -- JecelArticle: 90111
Adam Megacz wrote:
>Austin Lesea <austin@xilinx.com> writes:
>
>
>>Better Yield + Shorter Time = Lower Cost to Xilinx, which means Lower
>>Prices to customer.
>>
>>
The point is, the easy path parts are not known defects, they are simply
not tested as rigorously as the non-easy-path parts. Basically, they
reduce the test program to test only what your bitstream actually uses
in the design (and some testing of other unused logic, but not nearly as
rigorous). The result is significantly reduced testing time and
increased yield, which translates into a cost savings. What they
guarantee that way is only that it will work with your bitstream. It
could be a perfectly good part, or it could have a defect somewhere
where it doesn't affect your design. No one knows, because no one
tested it.
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 90112Antonio Pasini wrote: > > I have done the "tie all grounds together" mistake myself, so I know > > how you feel. > > Jecel, could you give me some advice on this ? Same application; maybe > using TI THS8133. This was a long time ago using the original ARM chipset. The video was only 24MHz, so it was hardly high speed by today's standards. Though I knew that the analog part should have separate power and ground I was busy with other things and didn't correct the layout guy when he failed to do this. The running programs generate a very visible pattern on the display and even in the speaker. At least this made debugging a little easier ;-) If you use all 10 bits available in the THS8133 instead of just 8 (24bpp) then I imagine it is even more important to get rid of the noise or else you might as well use the cheaper THS8134B instead. -- JecelArticle: 90113
Perhaps of some interest (subset of this presentation) "The NSEU Response of Static Latch Based FPGAs" original title on abstract: "The Continuing Impact of Design and Process Hardening on the NSEU Sensitivity of Advanced CMOS PLD Technologies" Joseph J Fabula and Austin Lesea, Xilinx 2005 MAPLD International Conference September 7-9, 2005, Washington, D.C. Abstract: http://klabs.org/mapld05/abstracts/175_fabula_a_.html Presentation: http://klabs.org/mapld05/presento/175_fabula_p.pdf -- rk Austin Lesea wrote: > (Real) Bob, > > Thanks for sending to me directly. > > There is an aerospace/defense FAE who will contact you shortly to > provide you with what you need (if we have what you need). > > I know we had Coolrunner II in the LANSCE facility in May of this year, > as it was my group that set it up, and was there for the testing. > > (surreal) Austin > > Bob wrote: > >> Sorry I don't use (real) info on newsgroups to keep spam to a minimum. >> I will email you with my (real) contact info. >> However I have tried before and was told that there was no info on the >> CoolRunner 2 as it is not intended for radiation and there are other >> parts that are designed for radiation. However that was last year. >> I have also searched on the NASA and ERRIC web sites and was >> unsuccessful in finding data. >> >> >> On Tue, 04 Oct 2005 11:55:47 -0700, Austin Lesea <austin@xilinx.com> >> wrote: >> >> >>>(Not Real) 'Bob', >>> >>>If you want an answer to this, why haven't you already contacted our >>>Xilinx Aerospace/Defense Field Applications Engineers? >>> >>>We have plenty of data that we are willing to share with (Real) >>>'customers'. >>> >>>If you need a contact, I can send their name to you once you email me >>>your (Real) 'Bob' email address (and real affiliation). >>> >>>It is Xilinx' interest to be sure that any aerospace/defense application >>>(as well as any other) of our products uses all of the best information >>>that we can provide. >>> >>>Austin >>> >>> >>> >>>Bob wrote: >>> >>> >>>>Hi I know that the CoolRunner2 CPLD TQ144, XC2C256-7TQ144I is not >>>>designed to be radiation tollerent, but... >>>> >>>>I would be interested if anyone reading this has ever radiated a CPLD >>>>or know of some CPLD radiation data on the web. >>>>I have google searched but found very little. >>>>Most ics like 74hc04 parts can take about 10,000 or more rads of total >>>>dose (Co60). >>>>I hope to do some total dose testing this month. >>>>Also as it has a reprogramable memory, it will be suseptible to SEU. >>>>I wont be able to test for that. >>>> >> >> -- rk, Just an OldEngineer "These are highly complicated pieces of equipment almost as complicated as living organisms. In some cases, they've been designed by other computers. We don't know exactly how they work." -- Scientist in Michael Crichton's 1973 movie, WestworldArticle: 90114
Bob, I agree with everything you wrote, but the original posting mentioned 1.8 MHz and 24 MHz. I did not make that up. It sure is not a typical modern design... I think we would agree that such a slow design will, almost inevitably, have a few ns slack to accomodate a possible metastable delay. If you use a 500 Mhz clock to synchronize a 400 MHz asynchronous data stream, the problem is much more real. I am so happy that we went to the trouble of measuring the delays on real (V2Pro) silicon, same as we had done with XC4000 years before. That gives us quantitative data. Less arm-waving. The rule still is: If you have reason to worry about metastability, give the flip-flop in question maximum slack to settle, and have it drive only one near-by synchronizing flip-flop. Without that precaution, you might get into trouble... Peter AlfkeArticle: 90115
Hi! I just asked my distributor for availiable Xilinx XC4VFX devices and found an XC4VFX20-10FF672CES2. Since I guess that ES means "Engineering sample", I was looking for informations about its limitations compared to the final device. But unluckily I failed. Maybe someone can give me a hint where to get these informations? Since I was inititally looking for a XC4VFX40, I figured out that this is not available currently. Is this right? Does someone know when this device gets available? Thank you very much, PeterArticle: 90116
On Tue, 04 Oct 2005 19:16:46 -0500, mvetromille@gmail-dot-com.no-spam.invalid (Melissa Vetromille) wrote: >Hello! > >I have a system implemented in hardware and I prototyped it in >VIrtex-II Pro platform with a testbench. I analyzed the signals using >chipscope and it worked the same as in simulation. After this, I >created a project in EDK and substituted the testbench by a >Microblaze processor. The project stopped working. Now, I need to >debug the harwdare in order to find the problem, ut I don't know how >to do this. I'm trying to use ModelSim. >In fact, I generated the simulation files and created the testbench >file to stimulate my system. However, this testbench just generates >the clock and reset, so I need instanciate my software in order to >generate the other stimulus. Is it possible? What do I have to do in >order to incorporate my software in simulation? Does anyone can help >me? > >Thank you! > >Melissa For me, the best way to debug hardware with a microblaze inside is to instantiate a ChipSocpe icon and ila inside the design, connected to the secondary bscan port of an opb_mdm connected to the microblaze. This way, you may debug hardware or software (not simultaneously) easily.Article: 90117
Melissa Vetromille wrote:
> Hello!
>
> I have a system implemented in hardware and I prototyped it in
> VIrtex-II Pro platform with a testbench. I analyzed the signals using
> chipscope and it worked the same as in simulation. After this, I
> created a project in EDK and substituted the testbench by a
> Microblaze processor. The project stopped working. Now, I need to
> debug the harwdare in order to find the problem, ut I don't know how
> to do this. I'm trying to use ModelSim.
> In fact, I generated the simulation files and created the testbench
> file to stimulate my system. However, this testbench just generates
> the clock and reset, so I need instanciate my software in order to
> generate the other stimulus. Is it possible? What do I have to do in
> order to incorporate my software in simulation? Does anyone can help
> me?
>
> Thank you!
>
> Melissa
>
If your tb entity name is Test_sim and if your EDK system instance is
UUT, add this to your testbech :
configuration tb_conf of Test_sim is
for testbench_arch
for UUT: system
use configuration work.system_conf;
end for;
end for;
end tb_conf;
Also, simulate the tb_conf configuration and not just your test bench
entity. (when selecting what to simulate).
EDK will also create a system.do or a .do to load everything needed IIRC.
Sylvain
Article: 90118"Peter Rauschert" <usenet@rauschert-online.de> schrieb im Newsbeitrag news:24r6k1962p1tlj7kskbpe9a9gmn72llub5@4ax.com... > Hi! > > I just asked my distributor for availiable Xilinx XC4VFX devices and > found an XC4VFX20-10FF672CES2. > > Since I guess that ES means "Engineering sample", I was looking for > informations about its limitations compared to the final device. But > unluckily I failed. > > Maybe someone can give me a hint where to get these informations? > > Since I was inititally looking for a XC4VFX40, I figured out that this > is not available currently. Is this right? Does someone know when this > device gets available? > > Thank you very much, > Peter Hi, Talk more to your disti, they should be able to get you shipping date (we did) for FX40 (no ES), another thing if you will happy with that. As of today all FX parts that may be available are ES. Again pressure your disti, Xilinx may be able to ship the parts you need, even if they dont show as available by the disti-first look AnttiArticle: 90119
Hi Austin,
>> So, can I then summarize that EasyPath is basically a standard Virtex
>> II/4 but with less time on the testbed (only the cells and routing used
>> by the customer are tested) in order to reduce cost?
>
> There is a basic 1's, 0's, shorts, leakage, etc test done to all parts,
> EasyPath or no.
Of course. The global die specs must be met.
> And then, for EasyPath, only those features used by the customer are
> tested (with the addition of any LUT pattern for the CLBs they use, and
> any IO strength for th IOB standard they use, which allows for the two
> most common ECO requests we got after we shipped). The difference in
> test time between as close as we can get to 100% testing for any
> possible use, and as close as we can get to 100% testing for one use is
> SIGNIFICANT.
Sounds quite reasonable. So, technologically there's nothing holding Altera
back in investing in a few extra ("standard") device testers and, as an
intermediate price-reduction step, doing same under the hereby trademarked
name "Crippledie" (come to think of it, sounds great as the title of an
ultra-violent FPS game taking place in a hospital or a leper colony too -
I'll have a chat with my local EA Games marketing guy).
I can't imagine that only partially testing an ASIC is patentable - but then
again, one-click-shopping is patentable as well according the USPTO so I
wouldn't be surprised.
Then of course there's HardCopy2, which, like EasyPath, only needs to be
tested with the user design _but also_ is a lot smaller in die size.
Thus:
Better Yield+Shorter Time+Smaller Area = Even Lower Cost to Altera, which
means even Lower Prices to customer. No ECO and no last-minute changes
though, I'll give you that.
Am I right?
Best regards,
Ben
Article: 90120what im asking is, we have "clock", which is an input to the entity and a signal called "clk" declared in the entity. The input "clock" is mapped to the signal "clk". In all other places only "clk" is used, but "clock" is never used. What is the difference of doing this from just using "clock" everywhere and eliminating "clk" altogether? CMOSArticle: 90121
Hi Antti! I just checked the website of AVNET for availability. Guess its a good thing to call them. Do you have informations concerning the special properties of the Virtex 4 Engineering Samples? Peter >"Peter Rauschert" <usenet@rauschert-online.de> schrieb im Newsbeitrag >news:24r6k1962p1tlj7kskbpe9a9gmn72llub5@4ax.com... >> Hi! >> >> I just asked my distributor for availiable Xilinx XC4VFX devices and >> found an XC4VFX20-10FF672CES2. >> >> Since I guess that ES means "Engineering sample", I was looking for >> informations about its limitations compared to the final device. But >> unluckily I failed. >> >> Maybe someone can give me a hint where to get these informations? >> >> Since I was inititally looking for a XC4VFX40, I figured out that this >> is not available currently. Is this right? Does someone know when this >> device gets available? >> >> Thank you very much, >> Peter > >Hi, > >Talk more to your disti, they should be able to get you shipping date (we >did) for FX40 (no ES), another thing if you will happy with that. As of >today all FX parts that may be available are ES. Again pressure your disti, >Xilinx may be able to ship the parts you need, even if they dont show as >available by the disti-first look > >Antti >Article: 90122
I've found out how to prevent the delays.. If you run rpcbind with the -i (insecure..) flag, there is no delay. (Well this is with BaseX but I don't see why it would be any different for WebPack) Still trying to figure out why my file dialogs complain about long paths though..Article: 90123
CMOS wrote: > what im asking is, we have "clock", which is an input to the entity and > a signal called "clk" declared in the entity. The input "clock" is > mapped to the signal "clk". In all other places only "clk" is used, but > "clock" is never used. What is the difference of doing this from just > using "clock" everywhere and eliminating "clk" altogether? I'd ask the question the other way round: why not call the input port 'clk'? NicolasArticle: 90124
Hi Peter, check the page with errata on xilinx-website : http://www.xilinx.com/xlnx/xweb/xil_publications_display.jsp?sGlobalNavPick=&sSecondaryNavPick=&category=-1210882&iLanguageID=1 Best regards, Bart
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