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
"rickman" <spamgoeshere4@yahoo.com> schrieb im Newsbeitrag news:3D78D726.A3FA9369@yahoo.com... > I have received an email reply from Xilinx which says that the XCR3384XL > device is significantly more expensive to make than the XCR3256XL and so > there are no plans to significantly reduce the price. Hmm, looks like a yield problem. So you will end up by using two 256er devices, wont you? -- MfG FalkArticle: 46726
I'm interested in partial reconfiguration of Xilinx FPGAs,
and have read all the relevant Xapps (151, 290, along with
all the relevant data sheets...), but they all refer to
Spartan-II and Virtex architectures
(which are essentially identical). Does anyone know
whether these documents can be applied to the Virtex-II
architectures (at least as far as the configuration
commands are concerned, if not the actual frame data)?
Also, I followed the "Small-Bit Manipulations" flow
described in Xapp290 and generated a bitstream (using bitgen
-g ActiveReconfig:Yes -r) targeting the Spartan-II chip.
However, when I look at the
generated bitstream, there are a series of undocumented
configuration commands. Specifically:
- Write to Frame Address Register (FAR)
- the address written is usually a frame between the
first one previously written and the next one to be
written
- Write to Command Register
- the command written is always 2, which is a reserved
command, and undocumented
- Write to register 14
- this register doesn't exist according to Xapp151, the
value written is always 0x00000000 00000000
- Write to FAR
- the address written is always 0x003a0e00
- Write 0x00000000 00000000 to register 14
- the above 2 steps are sometimes repeated
- after this sequence, the configuration of the next frame
starts.
I don't think that this is a problem with my translation
of the bit-stream, as there are too many regularities and
too many elements that translate correctly. Does anyone
have any ideas as to what this all amounts to?
Thanks in advance,
Pierre-Olivier
Article: 46727I have a design that place and routes giving a registered performance of just over 100MHz but looking at Tco I see that the numbers vary from 3/4 ns right up to 15 ns. What use is the registered performance figure Fmax of <10ns when the Tco varys so much? Surely Tco will dominate this design and the Fmax is misleading. Normally I specify a Tco of half the desired clock period. How do you assess the speed at which your system will reliably clock? What irks me is I'm using a global clock and a register on all outputs. I couldn't help feel somewhat agrieved by a Tco of 14.2ns (APEX 20KE 600 - 1X) I'll plug in the PLL later to see if that improves things. Can't wait to see what happens when I constrain the pinout :( Any suggestions appreciated.Article: 46728
"Paul Baxter" <pauljnospambaxter@hotnospammail.com> schrieb im Newsbeitrag news:3d78ebb4$0$1288$cc9e4d1f@news.dial.pipex.com... > I have a design that place and routes giving a registered performance of > just over 100MHz but looking at Tco I see that the numbers vary from 3/4 ns > > What irks me is I'm using a global clock and a register on all outputs. I Are you sure that all outputs are registered AND those registers are place inside the IOBs?? -- MfG FalkArticle: 46729
OR - just perhaps evaluate Lattice ispMACH4384 - it is available in 1.8, 2.5 and 3.3v versions - is also an extremely low current technology - Lattice went to an all CMOS gate structure in this family - no sense amplifiers to gobble up current. oops, affiliation and all that stuff - Michael Thomas LSC SFAE for the latest info on Lattice products - http://www.latticesemi.com >Subject: Re: XCR3384XL availability >From: "Falk Brunner" Falk.Brunner@gmx.de >Date: 9/6/2002 12:50 PM Eastern Daylight Time >Message-id: <alaqfe$1nqsji$1@ID-84877.news.dfncis.de> > >"rickman" <spamgoeshere4@yahoo.com> schrieb im Newsbeitrag >news:3D78D726.A3FA9369@yahoo.com... >> I have received an email reply from Xilinx which says that the XCR3384XL >> device is significantly more expensive to make than the XCR3256XL and so >> there are no plans to significantly reduce the price. > >Hmm, looks like a yield problem. So you will end up by using two 256er >devices, wont you? >--Article: 46730
Hi, Below I have code which when synthesized, it says the inputs are never
used. It compiles fine. I have them in equations so I don't know why it
thinks this. Did I code something wrong here that I just don't see? Probably
some obvious mistake.
Thanks!
This is the error message:
Synthesizing Unit <decide>.
Related source file is C:/MyDesigns/U19/synthesis/../src/Decide.vhd.
WARNING:Xst:646 - Signal <greenvalue> is assigned but never used.
WARNING:Xst:646 - Signal <difference> is assigned but never used.
WARNING:Xst:647 - Input <reset> is never used.
WARNING:Xst:647 - Input <clk> is never used.
WARNING:Xst:647 - Input <samplehold> is never used.
WARNING:Xst:647 - Input <datavalid> is never used.
WARNING:Xst:647 - Input <adcvalue<7>> is never used.
WARNING:Xst:647 - Input <adcvalue<6>> is never used.
WARNING:Xst:647 - Input <adcvalue<5>> is never used.
WARNING:Xst:647 - Input <adcvalue<4>> is never used.
WARNING:Xst:647 - Input <adcvalue<3>> is never used.
WARNING:Xst:647 - Input <adcvalue<2>> is never used.
WARNING:Xst:647 - Input <adcvalue<1>> is never used.
WARNING:Xst:647 - Input <adcvalue<0>> is never used.
Unit <decide> synthesized.
This is the code:
----------------------------------------------------------------------------
-----------------------
--
-- Title : Decide
-- Design : U19
-- Author : 0
-- Company : 0
--
----------------------------------------------------------------------------
-----------------------
--
-- File : C:\MyDesigns\U19\src\Decide.vhd
-- Generated : Thu Sep 5 09:07:33 2002
-- From : interface description file
-- By : Itf2Vhdl ver. 1.20
--
----------------------------------------------------------------------------
-----------------------
--
-- Description :
--
----------------------------------------------------------------------------
-----------------------
--{{ Section below this comment is automatically maintained
-- and may be overwritten
--{entity {Decide} architecture {Decide}}
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_arith.all;
use IEEE.std_logic_misc.all;
use IEEE.std_logic_unsigned.all;
entity Decide is
port(
reset : in std_logic;
clk : in std_logic;
samplehold : in std_logic;
datavalid : in std_logic;
adcvalue : in std_logic_vector(7 downto 0);
result : out std_logic_vector(3 downto 0)
);
end Decide;
--}} End of automatically maintained section
architecture Decide of Decide is
signal greenvalue: std_logic_vector(7 downto 0);
signal difference: std_logic_vector(7 downto 0);
begin
process(clk,reset)
begin
if (reset = '0') then
greenvalue <="00000000";
difference <= "00000000";
result<="0000";
elsif (clk'event and clk = '1') then
if(datavalid='1' and samplehold='0')then
greenvalue<=greenvalue+'1';
elsif (datavalid='1' and samplehold='1')then
difference<=difference+'1';
end if;
end if;
end process;
-- enter your statements here --
end Decide;
Article: 46731Falk, That is a bit unfair. Larger die parts cost more to make, because the yield is less. That is semiconductor physics 101. To imply a yield "problem" is misleading, and untrue. And, quite frankly, a bit absurd. After all, it is a CPLD, is absolutely tiny compared to the FPGAs that we make. Austin Falk Brunner wrote: > "rickman" <spamgoeshere4@yahoo.com> schrieb im Newsbeitrag > news:3D78D726.A3FA9369@yahoo.com... > > I have received an email reply from Xilinx which says that the XCR3384XL > > device is significantly more expensive to make than the XCR3256XL and so > > there are no plans to significantly reduce the price. > > Hmm, looks like a yield problem. So you will end up by using two 256er > devices, wont you? > -- > MfG > FalkArticle: 46732
Hi,
You only assign the signal Result with "0000".
The result of the synthesis is a module where the outputs Result is assign to
ground.
No input values will change that and therefore is removed from the netlist.
Göran Bilski
steve synakowski wrote:
> Hi, Below I have code which when synthesized, it says the inputs are never
> used. It compiles fine. I have them in equations so I don't know why it
> thinks this. Did I code something wrong here that I just don't see? Probably
> some obvious mistake.
>
> Thanks!
>
> This is the error message:
>
> Synthesizing Unit <decide>.
>
> Related source file is C:/MyDesigns/U19/synthesis/../src/Decide.vhd.
>
> WARNING:Xst:646 - Signal <greenvalue> is assigned but never used.
>
> WARNING:Xst:646 - Signal <difference> is assigned but never used.
>
> WARNING:Xst:647 - Input <reset> is never used.
>
> WARNING:Xst:647 - Input <clk> is never used.
>
> WARNING:Xst:647 - Input <samplehold> is never used.
>
> WARNING:Xst:647 - Input <datavalid> is never used.
>
> WARNING:Xst:647 - Input <adcvalue<7>> is never used.
>
> WARNING:Xst:647 - Input <adcvalue<6>> is never used.
>
> WARNING:Xst:647 - Input <adcvalue<5>> is never used.
>
> WARNING:Xst:647 - Input <adcvalue<4>> is never used.
>
> WARNING:Xst:647 - Input <adcvalue<3>> is never used.
>
> WARNING:Xst:647 - Input <adcvalue<2>> is never used.
>
> WARNING:Xst:647 - Input <adcvalue<1>> is never used.
>
> WARNING:Xst:647 - Input <adcvalue<0>> is never used.
>
> Unit <decide> synthesized.
>
> This is the code:
>
> ----------------------------------------------------------------------------
> -----------------------
>
> --
>
> -- Title : Decide
>
> -- Design : U19
>
> -- Author : 0
>
> -- Company : 0
>
> --
>
> ----------------------------------------------------------------------------
> -----------------------
>
> --
>
> -- File : C:\MyDesigns\U19\src\Decide.vhd
>
> -- Generated : Thu Sep 5 09:07:33 2002
>
> -- From : interface description file
>
> -- By : Itf2Vhdl ver. 1.20
>
> --
>
> ----------------------------------------------------------------------------
> -----------------------
>
> --
>
> -- Description :
>
> --
>
> ----------------------------------------------------------------------------
> -----------------------
>
> --{{ Section below this comment is automatically maintained
>
> -- and may be overwritten
>
> --{entity {Decide} architecture {Decide}}
>
> library IEEE;
>
> use IEEE.std_logic_1164.all;
>
> use IEEE.std_logic_arith.all;
>
> use IEEE.std_logic_misc.all;
>
> use IEEE.std_logic_unsigned.all;
>
> entity Decide is
>
> port(
>
> reset : in std_logic;
>
> clk : in std_logic;
>
> samplehold : in std_logic;
>
> datavalid : in std_logic;
>
> adcvalue : in std_logic_vector(7 downto 0);
>
> result : out std_logic_vector(3 downto 0)
>
> );
>
> end Decide;
>
> --}} End of automatically maintained section
>
> architecture Decide of Decide is
>
> signal greenvalue: std_logic_vector(7 downto 0);
>
> signal difference: std_logic_vector(7 downto 0);
>
> begin
>
> process(clk,reset)
>
> begin
>
> if (reset = '0') then
>
> greenvalue <="00000000";
>
> difference <= "00000000";
>
> result<="0000";
>
> elsif (clk'event and clk = '1') then
>
> if(datavalid='1' and samplehold='0')then
>
> greenvalue<=greenvalue+'1';
>
> elsif (datavalid='1' and samplehold='1')then
>
> difference<=difference+'1';
>
> end if;
>
> end if;
>
> end process;
>
> -- enter your statements here --
>
> end Decide;
Article: 46733
Check the Virtex II Platform FPGA handbook page 388 for information
about the configuration registers in VII. For example, register 14 is
the Product ID Code register.
Phil
Pierre-Olivier Laprise wrote:
>
> I'm interested in partial reconfiguration of Xilinx FPGAs,
> and have read all the relevant Xapps (151, 290, along with
> all the relevant data sheets...), but they all refer to
> Spartan-II and Virtex architectures
> (which are essentially identical). Does anyone know
> whether these documents can be applied to the Virtex-II
> architectures (at least as far as the configuration
> commands are concerned, if not the actual frame data)?
>
> Also, I followed the "Small-Bit Manipulations" flow
> described in Xapp290 and generated a bitstream (using bitgen
> -g ActiveReconfig:Yes -r) targeting the Spartan-II chip.
> However, when I look at the
> generated bitstream, there are a series of undocumented
> configuration commands. Specifically:
> - Write to Frame Address Register (FAR)
> - the address written is usually a frame between the
> first one previously written and the next one to be
> written
> - Write to Command Register
> - the command written is always 2, which is a reserved
> command, and undocumented
> - Write to register 14
> - this register doesn't exist according to Xapp151, the
> value written is always 0x00000000 00000000
> - Write to FAR
> - the address written is always 0x003a0e00
> - Write 0x00000000 00000000 to register 14
> - the above 2 steps are sometimes repeated
> - after this sequence, the configuration of the next frame
> starts.
>
> I don't think that this is a problem with my translation
> of the bit-stream, as there are too many regularities and
> too many elements that translate correctly. Does anyone
> have any ideas as to what this all amounts to?
> Thanks in advance,
>
> Pierre-Olivier
--
--------------------------------------------------------------
__
/ /\/ Dr Phil James-Roxby Direct Dial: 720.652.3767
\ \ Researcher Fax : 720.652.3599
/ / Design Technology Group
\_\/\ Xilinx Labs @ Longmont,CO Phil.James-Roxby@xilinx.com
--------------------------------------------------------------
Article: 46734Jerry D. Harthcock <jerry@quickcores.com> wrote: : "Josh Model" <model@ll.mit.edu> wrote in message news:<wkc89.44$I7.3516@llslave.llan.ll.mit.edu>... :> Has anyone come across any 3rd party prototype boards for Actel FPGA's? :> It seems as if Actel's stuff starts at ~$1k, and I was looking for one :> closer to the $500 range. :> :> Thanks, :> --Josh : QuickCores offers a low cost IP Delivery System based on Actel's new : ProASIC+. : Prices start at $175 for the APA075. It's all self-contained in that : no external device programmer is required. It also includes a : built-in JTAG boundary scan controller and built-in JTAG real-time : debug controller for microcontroller designs. No JTAG pod is required : since everything is done via RS-232 using Actel Libero-generated STAPL : files. : It's all packaged in a 28-pin postage stamp form factor for easy : prototyping. It's called the Musketeer (All-for-One Stamp). : Visit www.quickcores.com for info. : Regards, : Jerry Looks interesting. Actel has a parallel port/jtag interface for downloading but it looks like you built that on the module with power supplys and a debugger. So how do you guys make your money? 1) selling modules as a development tool. 2) selling modules for products. 3) licensing cores. 4) any way you can. Can we take a design developed on your module and download the bits to an actel part mounted on our board? Any chance of doing a serial/jtag programming debug module that would program and control an actel part on our board? Is the serial protocol open or propritary? John Eaton Reply address is a spam trap. use first_last @ hp.com instead.Article: 46735
"Austin Lesea" <austin.lesea@xilinx.com> schrieb im Newsbeitrag news:3D78F606.8ED58F61@xilinx.com... > Falk, > > That is a bit unfair. > > Larger die parts cost more to make, because the yield is less. That is > semiconductor physics 101. Iam afraid you got me wrong. There was absolutely NO pun intended. What I wanted to say is, that it looks like a yield problem in general, not that Xilinx (or its FAB) is doing a bad job. But it is suprising, that a chip with 50% more logic capacity (50 % more die area??) is 3.5 times more expensive. Again, this is not intended to attack anyone. -- MfG Falk P.S. Yes, I know that many (most??) things in engineering does'nt scale linear. ;-))Article: 46736
Falk, OK, no problem. It is a mystery. Peter or I will find out why the price differential. Could be just plain old market forces...... Austin Falk Brunner wrote: > "Austin Lesea" <austin.lesea@xilinx.com> schrieb im Newsbeitrag > news:3D78F606.8ED58F61@xilinx.com... > > Falk, > > > > That is a bit unfair. > > > > Larger die parts cost more to make, because the yield is less. That is > > semiconductor physics 101. > > Iam afraid you got me wrong. There was absolutely NO pun intended. > What I wanted to say is, that it looks like a yield problem in general, not > that Xilinx (or its FAB) is doing a bad job. > > But it is suprising, that a chip with 50% more logic capacity (50 % more die > area??) is 3.5 times more expensive. > Again, this is not intended to attack anyone. > > -- > MfG > Falk > > P.S. Yes, I know that many (most??) things in engineering does'nt scale > linear. > ;-))Article: 46737
> Ooops. What I wrote in my last posting was wrong. Hope my logic is > better this time. > > For a block size of n = 256, the array trig_256 has 320 (= 5*n/4) > elements, each of which is a signed 32. > > Since T is used to index the trig_256 array, T should be of width 9. > > Therefore, > > macro expr trigsize log2ceil(5*n/4); > unsigned <trigsize> T; > > should do the trick. Would this work?! Yes, with a slight correction : macro expr TRIG_WIDTH = log2ceil(5*n/4); Then declare any index variable t for your array trig_256[ ] as unsigned TRIG_WIDTH t; Note how I'm using upper case for names of constants, lower case for variable names, as I mentioned before. Its not strictly necessary, but it will make your code more easily understood by others! So change that ugly "n" to something more meaningful now! In general, a unsigned number that ranges from 0 to N inclusive needs log2ceil(N+1) bits for storage. Now say you have declared an array int my_array[M]; An index for my_array[ ] is a unsigned number which ranges from 0 to (M-1) inclusive. So this index needs log2ceil(M) bits for storage. This is how the Handel-C compiler works out how wide index values for arrays should be. Writing this calculation as a compile-time constant expression is definitely the Right Thing to do, as you attempted with "trigsize" in your post. This means that its easy for you to change n in the future, as TRIG_WIDTH is recalculated for you when you recompile ie. let the compiler work out bitwidths for you. Cheers, SteffanArticle: 46738
> Are you sure that all outputs are registered AND those registers are place > inside the IOBs?? I guess that was why I said 'what irks me' It must not be putting the registers on the IOBs or the global clock is hugely delayed around the device. I assumed that with no pre-existing assignments Quartus 2 PAR would put the final registers on the IOBs. I'm now wondering because a lot of these outputs are from a ROM-based state machine (Thanks Peter Alfke for reminding me of the technique) but if it uses the ESB registered outputs and then routes to a latchless IOB that could be causing it.... Thanks for jogging my memory. I think I'll put an extra pipeline stage on my outputs to be sure. In essence my question still stands. An Fmax figure is meaningless if the Tco (or indeed Tsetup/hold) are excessive. Its OK for some types of inputs/outputs but not for those needing to be operating at full speed in a synchronous system. I just evaluated an SDRAM core which claimed 88MHz + but has Tco's up at 15 ns for the SDRAM interface. I'm now running into similar issues in my own design and I think Tco's that high are a big show stopper, but I'm asking if I'm right or not. Paul BaxterArticle: 46739
these are the type of answers that i dislike John_H :-(... what i want to tell is that usually the user will be restricted with off chip interface performances and so there is no need to tighten a lot the design. as i said ~33 Mhz is enough for 512*512 image processing, behavioral VHDL will be more than enough for me you have a CPU of 2GHZ, but your system works less becaue of the CPU intereface this was my point John_H <johnhandwork@mail.com> wrote in message news:<3D7784D5.8C7480F5@mail.com>... > I was able to run programs on a 6 MHz IBM AT computer. Nowadays we have 2 GHz > machines. > > so why the need for higher speed? > (rhetorical) > > hristo wrote: > > > in image processing and with color PAL , 33.32 Mhz is enough to do real time, > > with less image size, the sufficient speed is much less > > so why the need for higher speed? > > > > any practical casesArticle: 46740
> > in image processing and with color PAL , 33.32 Mhz is enough to do real time, > > with less image size, the sufficient speed is much less > > so why the need for higher speed? > > (Pardon my ignorance, but where does this 33.32 MHz number come from? > It doesn't seem to be related to PAL square pixel sample rate, or > the 13.5 MHz CCIR 601 sample rate. What is it, and why do you think > it is enough?) this what has been given to me from a friend Pal (720*580)*25(frames)*3(RGB)---->=33mhzArticle: 46741
The original question was: Why four times the price for 50% more macrocells? Here is an attempt at a rational explanation. There are five factors that contribute to disproportionate pricing: 1. More chip area. CPLDs don't grow linearily, their interconnect grows faster.(Different from FPGAs) 2. Lower yield due to defect density on the wafer. That increases the cost for any die faster than the growth of the die area. (Semiconductor Physics 101) 3. Lower production volume. High volume drives cost down. The reverse is also true. 4. Fancier package. 5. And finally: Less competitive pressure. Everybody will understand this. These are the five factors that make the '384 overproportionally more expensive than the '256. You might argue about each individual factor, but you cannot overcome their composite effect. But CoolRunner-II uses smaller geometries and will be less expensive... Peter Alfke, Xilinx ApplicationsArticle: 46742
The FrameAdderssRegister (FAR) hold the address the want your write to start at. Same for V1 and V2. Write to CMD register. A 2 is reserved in V1 and is a Multi-Frame write in a V2. The write to register 14 is to match the Product in the part. I'm guessing it flag an error is it is the wrong part number. I'm not clear about the FAR write to 0x003a0e00 this looks like some address inside the device. Steve "Pierre-Olivier Laprise" <plapri@tesserae.McRCIM.McGill.EDU> wrote in message news:Ln5e9.2205$016.292871@charlie.risq.qc.ca... > I'm interested in partial reconfiguration of Xilinx FPGAs, > and have read all the relevant Xapps (151, 290, along with > all the relevant data sheets...), but they all refer to > Spartan-II and Virtex architectures > (which are essentially identical). Does anyone know > whether these documents can be applied to the Virtex-II > architectures (at least as far as the configuration > commands are concerned, if not the actual frame data)? > > Also, I followed the "Small-Bit Manipulations" flow > described in Xapp290 and generated a bitstream (using bitgen > -g ActiveReconfig:Yes -r) targeting the Spartan-II chip. > However, when I look at the > generated bitstream, there are a series of undocumented > configuration commands. Specifically: > - Write to Frame Address Register (FAR) > - the address written is usually a frame between the > first one previously written and the next one to be > written > - Write to Command Register > - the command written is always 2, which is a reserved > command, and undocumented > - Write to register 14 > - this register doesn't exist according to Xapp151, the > value written is always 0x00000000 00000000 > - Write to FAR > - the address written is always 0x003a0e00 > - Write 0x00000000 00000000 to register 14 > - the above 2 steps are sometimes repeated > - after this sequence, the configuration of the next frame > starts. > > I don't think that this is a problem with my translation > of the bit-stream, as there are too many regularities and > too many elements that translate correctly. Does anyone > have any ideas as to what this all amounts to? > Thanks in advance, > > Pierre-OlivierArticle: 46743
So would an appropriate restatement of your original post be something like: "In an image processing application where I have no external interfaces running more than 33.32 MHz (smaller image sizes have lower external speeds) why would a designer want devices that can achieve higher sppeds for this application?" ? If so, your original post would come across less as "Why in the world would anyone want a device capable of speeds higher than 33.32MHz?" which is how I interpreted your question. I tried to illustrate the short-sighted nature of my interpretation with a practical comparison of older/slower technology with newer/faster versions. I do apologize for trying to make light of your question since it wasn't possible for me to fully understand your intent. hristo wrote: > these are the type of answers that i dislike John_H :-(... > > what i want to tell is that usually the user will be restricted with > off chip interface performances and so there is no need to tighten a > lot the design. as i said ~33 Mhz is enough for 512*512 image > processing, behavioral VHDL will be more than enough for me > > you have a CPU of 2GHZ, but your system works less becaue of the CPU > intereface > this was my point > > John_H <johnhandwork@mail.com> wrote in message news:<3D7784D5.8C7480F5@mail.com>... > > I was able to run programs on a 6 MHz IBM AT computer. Nowadays we have 2 GHz > > machines. > > > > so why the need for higher speed? > > (rhetorical) > > > > hristo wrote: > > > > > in image processing and with color PAL , 33.32 Mhz is enough to do real time, > > > with less image size, the sufficient speed is much less > > > so why the need for higher speed? > > > > > > any practical casesArticle: 46744
A faster chip lets you do more with less hardware. We've done a number of NTSC image
processors that use an 8x or 12x pixel rate clock. Doing that lets you do the
processing (filtering, thresholding, motion detection, labelling, etc) using bit serial
arithmetic. You can fit quite a complicated video processor into a small FPGA by doing
bit serial processing. Running on a faster clock also lets you use a single SDRAM for
your frame buffering and make it look like a multiported device to your process, since
you can get 8 or more accesses per pixel time.
hristo wrote:
> these are the type of answers that i dislike John_H :-(...
>
> what i want to tell is that usually the user will be restricted with
> off chip interface performances and so there is no need to tighten a
> lot the design. as i said ~33 Mhz is enough for 512*512 image
> processing, behavioral VHDL will be more than enough for me
>
> you have a CPU of 2GHZ, but your system works less becaue of the CPU
> intereface
> this was my point
>
> John_H <johnhandwork@mail.com> wrote in message news:<3D7784D5.8C7480F5@mail.com>...
> > I was able to run programs on a 6 MHz IBM AT computer. Nowadays we have 2 GHz
> > machines.
> >
> > so why the need for higher speed?
> > (rhetorical)
> >
> > hristo wrote:
> >
> > > in image processing and with color PAL , 33.32 Mhz is enough to do real time,
> > > with less image size, the sufficient speed is much less
> > > so why the need for higher speed?
> > >
> > > any practical cases
--
--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: 46745We finally got around to measuring metastabity. We used the CLB flip-flops in our newest Virtex-IIPro device (130 nm technolgy, 1.5 Vcc) and clocked them at around 350 MHz with an asynchronous input of roughly 50 MHz. This should represent agressive modern operating conditions. We then measured the number of metastable events per minute as a function of the time between clocking the flip-flop under test, and a variable clock delay at the observation flip-flop that checks for metastable events. This method is described in detail in XAPP094, and I first used and documented it in 1988 (!). The concept seems to have passed the test of time. Here are the measured results: Metastable events for a clock-to-clock delay of 1300 ps: ~ 30,000 errors per minute 1400 ps: ~ 2,000 errors per minute 1500 ps: ~ 100 errors per minute 1600 ps: = 10 errors per minute These are short-time measurements of a statistical event, but I am willing to estimate that the time between metastable events increases by a factor of roughly 200 for every 200 picoseconds of extra delay between the two clocks. That leads to the following extrapolation: If you synchronize a 50 MHz asynchronous event with a roughly 350 MHz clock, and you allow only 1.2 ns for clock-to-out plus set-up time plus routing to the flip-flop in the adjacent CLB, your design will go metastable very often; the Mean Time Between Failure will be about 0.1 ms. But watch what happens when the timing gets more relaxed: Changing the total delay of 1.2ns to 1.4 ns leads to MTBF=30 ms 1.6 ns leads to MTBF= 6 sec 1.8 ns leads to MTBF= 20 min 2.0 ns leads to MTBF= 4000 min = 66 hrs 2.2 ns leads to MTBF= 13,000 hrs = 18 months 2.4 ns leads to MTBF= 3,600 months = 300 years 2.6 ns leads to MTBF= 60,000 years 2.8 ns leads to MTBF= 12 million years In other words, you can synchronize ~50 MHz with a 350 MHz clock, take advantage of the difference between the inherent 1.2 ns and the 350 MHz clock period of 2.8 ns, and your design will exceed the allowed propagation delay of one clock period only once every 12 million years. For lower clock rates and less frequent asynchronous events, MTBF increases with the inverse of the product of the two frequencies, i.e. for a 100 MHz clock synchronizing a ~ 10 MHz asynchronous event, multiply the MTBF by a factor 3.5 x 5 = 17.5 More details will be published soon. The lack of modern quantative data has been a thorn in my side, and I want to let you know these encouraging results immediately. I think we can say that modern CMOS flip-flops recover extremely fast from any metastable event. :-) I want to thank Yiding Wu for his enthusiastic help and patience doing these measurements. Peter Alfke, Xilinx ApplicationsArticle: 46746
Hi all, Thanks for your replies. I think my question has been answered. But for clarity's sake I will exaplin what I intended to ask. My design goes through synthesis and place & route and the final timing numbers as given by the Quartus 2 tool after placement says that the design works at 40 MHz. I would assume that when this design sees actual FPGA silicon, there would be a performance degradation (maybe a small one). But it looks like (from your answers) that its not so. Which means the timing analyzer took into consideration all possible delays that could occur in actual silicon. Thanks again, Prashant Peter Alfke <peter@xilinx.com> wrote in message news:<3D78D30B.1FDD3AEF@xilinx.com>... > I obviously cannot speak for Altera, but... > I found your first paragraph confusing. When you synthesize a design and > it works at 40 MHz, well than it does work at 40 MHz. How could it > possibly get slower? > You must have some question on your mind, but I do not understand it. > Always glad to help. > Peter Alfke, Xilinx Applications > ====================================== > Prashant wrote: > > > Hi, > > > > What sort of degradation can be expected in performance of a design > > once it is ported onto an FPGA. for e.g. if a 20000 LE design works at > > 40 MHz when synthesized in Quartus II on a Apex20KE1500 device, how > > much worse can it get when it actually gets implemented on the above > > device ? > > > > Also, Altera seems to offer an online course for Examining & Improving > > Timing Results in Quartus Software for $95 for a month. Has anyone had > > any experience with this course ? Does it really help as it claims ? > > > > I appreciate all the help. > > > > Thanks, > > PrashantArticle: 46747
First, WINE may be immaterial to you, but the original purpose of my post was to clear any misconception that WINE would be required for the Quartus II 2.1 (or 2.0) Linux Edition. WINE is not required, as the Quartus II 2.1 (or 2.0) Linux Edition is a Native Linux solution. This is crucial to many users who are investing in a Linux environment and prefer Native Linux solutions for their work, over a Windows environment. Today's PC Hardware/Linux solution offers compelling values to those who prefer UNIX, but would like high performance, low cost open standards based computing platforms. ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- ------ It is good you clarified your post, by saying that you were using Quartus II 1.1 SP1 for your current project. Your reasons for using Leonardo with Quartus II 1.1 SP1 are perfectly understandable, and as you pointed out, Altera would not be providing Leonardo, if they felt that their native HDL synthesis was doing a decent job. In my original post, I said a full working flow for Linux was available from Altera using the Quartus II 2.1 Linux Solution, using native synthesis. I specifically said Quartus II 2.1 and not Quartus II 2.0, because I understand the need for a good HDL (VHDL, Verilog) synthesis and simulation solution from Altera or any other EDA vendor is needed to adopt the Linux platform for serious day to day work. Altera has made significant improvements to their HDL language processing capabilities in Quartus II 2.1, which makes this flow viable. To specifically answer questions that you raised regarding the Quartus II 2.1 native synthesis capabilities and, I am quoting using Altera press releases, or my own personal experience with Quartus II 2.1: >1) Generics - you imply they are fully supported now. That's great. I can pass generics of all types? or just integers? to all code or just megafunctions? Yes, GENERICS in VHDL of all types are fully supported. There is a limit on the length of string parameters. It is a large number. Parameter passing between mixed languages i.e. VHDL, Verilog and AHDL is supported well. If you feel there are specific issues with GENERIC support, you can post code snippets that work for you in other tools, and I can verify what they do in Quartus II 2.1. >2) Has the VHDL parser/syntax checker been re-written more robustly? "The Quartus II version 2.1 development software also includes improvements to the integrated synthesis tool. This new synthesis technology also includes language extractors licensed from Verific Design Automation Inc.". The link is http://biz.yahoo.com/prnews/020715/sfm041_1.html. Verific's link is www.verific.com This provides improvements in both the quality of language support for both VHDL and Verilog, and the response of the Quartus II software when incorrect syntax is detected. >3) Have Altera made claims that the synthesis results are improved and perhaps even on a par with say Leonardo level 1? Can they show large designs that bear this out? What I can say, is that you are free to try this out and form your own judgment. The results will be design specific. With good solid language support in Quartus II 2.1, this comparison between tools is straightforward. With Quartus II 2.1 there are additional optimization techniques like logic duplication and register retiming which will provide a means to obtain better performance. These techniques are available whether you use the output from a synthesis tool or the Quartus II 2.1 native HDL synthesis. http://www.electronicstimes.com/story/OEG20020830S0014 What I post is my own opinion, and only information available in the public domain. -DS "Paul Baxter" <pauljnospambaxter@hotnospammail.com> wrote in message news:3d787131$0$8511$cc9e4d1f@news.dial.pipex.com... > The reason for my post was to argue that claims that a Linux version of > Quartus (usage or not of WINE is immaterial to me) providing a full > development environment need to be substantiated. My particular feeling is > that the Quartus 2 synthesiser and VHDL parsing/error checking (as of v1.1 > SP2 admittedly) are far too poor to be considered for any non-trivial > development. > > > Could you clarify your statement "I really have given the native > Quartus > > 2 synthesiser lots of outings" by specifying the version of Quartus II was > > used ? The reply to Prager referred to Quartus II 2.1, and maybe you could > > share your results for the quality of the HDL processing for Quartus II > 2.1, > > for your unmodified design with GENERICS. > > OK > > Used version 1.0 through ver 1.1 SP2. A large project began whilst using > v1.1 SP2 so I have frozen development to using that version. I have > monitored subsequent releases but haven't found a compelling feature or bug > fix that would warrant the update considering I'd probably need to do my > timing simulations again. > > That said until I hear reports on the ng extolling new-found virtues I will > not use windows Quartus 2 for synthesis - just place and route. I would LOVE > someone to tell me its hugely better now though as an integrated design flow > is preferred from ease of use standpoint. > > Since I haven't used v2.1 I cannot comment definitively. I really hope it is > a lot better, but until a Linux Quartus 2 user definitively tells me it is a > robust useful development environment (and not just something that works > some of the time) I'm not willing to take Altera at face value. I urge > others to be cautious before relying on it too. > > Please don't mistake this for Linux-bashing. I would LOVE Quartus 2 to be > available on both Windows and Linux (and elsewhere for that matter) just > evaluate its strengths and weaknesses before claiming it a complete > development environment. > > I'm fairly happy with using Leonardo for the synthesis (which I did upgrade > to fix a couple of annoying synthesis bugs in 2001_1d) and Quartus II just > for place/route. This route is sadly not available on Linux (though I would > imagine this would be far easier to port to Linux than Quartus 2 was). > > I just had a LOT of grief and several months of ultimately wasted effort > with the Quartus 2 synthesiser so when I see recommendations to use it in a > practical system I feel the need to answer. > > Frankly I wish Altera were more up front about the deficiencies of its > synthesiser. There is a reason they bundle Leonardo to get any sort of > reasonable results. > > You are right that I should look at 2.0 and 2.1 but only when this project > closes. > > Back to you. My questions: > > 1) Generics - you imply they are fully supported now. That's great. I can > pass generics of all types? or just integers? to all code or just > megafunctions? > > 2) Has the VHDL parser/syntax checker been re-written more robustly? > Crashing during > > 3) Have Altera made claims that the synthesis results are improved and > perhaps even on a par with say Leonardo level 1? Can they show large designs > that bear this out? > > Oh and are you connected with Altera or just a concerned citizen? > > Paul > > Just to clarify, there is a lot to praise about the Altera software too > particularly in ease of use for beginners. > I just wish sometimes that rather than adding new bolt-on features and > making big increases to the version number they'd focus on getting right > what they have. > >Article: 46748
John Eaton <johne@hpvcljte.vcd.hp.com> wrote in message news:<alb0ti$em8$1@news.vcd.hp.com>... > Jerry D. Harthcock <jerry@quickcores.com> wrote: > : "Josh Model" <model@ll.mit.edu> wrote in message news:<wkc89.44$I7.3516@llslave.llan.ll.mit.edu>... > :> Has anyone come across any 3rd party prototype boards for Actel FPGA's? > :> It seems as if Actel's stuff starts at ~$1k, and I was looking for one > :> closer to the $500 range. > :> > :> Thanks, > :> --Josh > > : QuickCores offers a low cost IP Delivery System based on Actel's new > : ProASIC+. > : Prices start at $175 for the APA075. It's all self-contained in that > : no external device programmer is required. It also includes a > : built-in JTAG boundary scan controller and built-in JTAG real-time > : debug controller for microcontroller designs. No JTAG pod is required > : since everything is done via RS-232 using Actel Libero-generated STAPL > : files. > > : It's all packaged in a 28-pin postage stamp form factor for easy > : prototyping. It's called the Musketeer (All-for-One Stamp). > > : Visit www.quickcores.com for info. > > : Regards, > > : Jerry > > > Looks interesting. Actel has a parallel port/jtag interface for downloading > but it looks like you built that on the module with power supplys and a > debugger. So how do you guys make your money? > > 1) selling modules as a development tool. > > 2) selling modules for products. > > 3) licensing cores. > > 4) any way you can. > > > Can we take a design developed on your module and download the bits to an > actel part mounted on our board? > > Any chance of doing a serial/jtag programming debug module that would program > and control an actel part on our board? > > Is the serial protocol open or propritary? > > > > > John Eaton > > > > > Reply address is a spam trap. use first_last @ hp.com instead. The Musketeer was originally intended that it be designed right into the end application board because of its 28-pin "stamp" form factor. You can socket it for about 25 cents. The nice thing about having everything built in is that it can be re-programmed remotely, and the implemented micro debugged/monitored in real time using the built-in RS-232 port. With the built-in JTAG boundary scan controller, you can also do boundary scan testing of the part even after its installed in the field, and do it remotely. All you need is an RS-232 connection to a PC. "Yes", to (1)-(4) above. We also sell debuggers and do custom implementations as well. There is a Musketeer product brief at our web site, www.quickcores.com. Listed are all the FBGA ball numbers used by the built-in "helper" micro and these are reserved. Otherwise, you should be able to implement whatever design you want. With respect to "downloading bits", the Musketeer's ProASIC+ is programmed by "playing" a STAPL file over its RS-232 port. The STAPL file is the very STAPL file created by Libero. So if your hook-ups are the same and the target APAxxx device is the same, then you should be able to use the same STAPL file. If not, you can simply go into Libero's Pin Edit and shuffle your pins around to conform to your application board, and then simply re-route followed by STAPL generation. We could build a stamp form factor programmer/debugger/boundary scan controller that you could design into your board. We've discussed this but no one has demanded it yet. It would essentially be a Musketeer minus the ProASIC+ device. The serial protocols are proprietary but are available under terms of the license that comes with the programmer/debugger software. Regards, JerryArticle: 46749
>In my original post, I said a full working flow for Linux was available from >Altera using the Quartus II 2.1 Linux Solution, using native synthesis. I >specifically said Quartus II 2.1 and not Quartus II 2.0, because I >understand the need for a good HDL (VHDL, Verilog) synthesis and simulation >solution from Altera or any other EDA vendor is needed to adopt the Linux >platform for serious day to day work. Altera has made significant >improvements to their HDL language processing capabilities in Quartus II >2.1, which makes this flow viable. ... I'm not familiar with the Altera tools. Is a GUI mentality required, or are they friendly to make files? Are the intermediate file formates documented? Is it possible to write supplimental tools/hacks and merge them into the flow? -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.
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