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 58475

Article: 58475
Subject: Re: XST fails to recognize FSM with registered outputs
From: Sergei Storojev <storojev@xilinx.com>
Date: Thu, 24 Jul 2003 17:27:58 +0200
Links: << >>  << T >>  << A >>
Dear Eilert,

The description style you used in ELIS_Statemachine example will be
supported in the next release of ISE.

In the case you replace
         case NS is
by
         case CS is

in the process

	Sync_Output : process (Reset, Clock)

then XST will be able to recognize FSM (but of course in this case it is
not the same behavior).

Thank you,
Sergei.

E. Backhus wrote:
> Hi everybody,
> while I was trying to create a statemachine with registered outputs
> which shouldn't be delayed by one clock cycle (as usual when just
> putting a register behind the outputs of the FSM) I modified some
> sourcecode from the XILINX ISE Language Templates for sythesis. As an
> example I tried to recreate the stopwatch statemachine from the ISE 5
> In depth tutorial.
> 
> Everything works fine insofar that the function is correct and
> itentical to the original design and it also synthesizes fine with one
> little exeption:
> 
> The XST-Synthesis Tool does not recognize my coding style as a FSM,
> therefore it wont do the neccessary optimizations. For comparision
> purposes I have added some XST-synthesis report snippets to outline
> the differences:
> 
> While my coding style produces a register and some feedback logic
> around it, for the original code (Produced by StateCAD) XST inferes a
> FSM and applies all optimizations on it.
> 
> (When I comment out the enum_encoding attributes in my code then
> register CS will become One-State-Hot encoded, but no OSH-FSM will be
> created. Instead some clumsy binary FSM with an unreal OSH encoding
> (all statebits zero!!! - not allowed for OSH encoding!!!) will be
> generated.
> 
> So, what trick makes the XST-Synthesis tool recognize my coding style
> to be a FSM working in the way I want (that is with registered outputs
> but no delay by one clock cycle)?
> 
> 
> All help is appreciated.
> 
> Thanks 
> 
>  Eilert
> 
> 
> 
> =========================================================================
> *                           HDL Synthesis                             
>  *
> =========================================================================
> 
> Synthesizing Unit <elis_statemachine>.
>     Related source file is
> S:/ssy_laboratory_test/ssy_stopwatch/ELIS_Statemachine.vhd.
>     Found 1-bit register for signal <clockenableout>.
>     Found 1-bit register for signal <resetout>.
>     Found 3-bit register for signal <cs>.
>     Summary:
> 	inferred   5 D-type flip-flop(s).
> Unit <elis_statemachine> synthesized.
> 
> 
> =========================================================================
> HDL Synthesis Report
> 
> Macro Statistics
> # Registers                        : 3
>   3-bit register                   : 1
>   1-bit register                   : 2
> 
> =========================================================================
> 
> 
> 
> =========================================================================
> *                           HDL Synthesis                             
>  *
> =========================================================================
> 
> Synthesizing Unit <stmach>.
>     Related source file is
> S:/ssy_laboratory_test/ssy_stopwatch/STMACH.vhd.
>     Found finite state machine <FSM_0> for signal <sreg>.
>     -----------------------------------------------------------------------
>     | States             | 6                                          
>    |
>     | Transitions        | 11                                         
>    |
>     | Inputs             | 1                                          
>    |
>     | Outputs            | 2                                          
>    |
>     | Reset type         | asynchronous                               
>    |
>     | Encoding           | automatic                                  
>    |
>     | State register     | d  flip-flops                              
>    |
>     -----------------------------------------------------------------------
>     Summary:
> 	inferred   1 Finite State Machine(s).
> Unit <stmach> synthesized.
> 
> 
> =========================================================================
> HDL Synthesis Report
> 
> Macro Statistics
> # FSMs                             : 1
> 
> =========================================================================
> 
> Optimizing FSM <FSM_0> with One-Hot encoding and d flip-flops.
> 
> 
> 
> Sourcecode of elis_statemachine.vhd:
> 
> library IEEE;
> use IEEE.STD_LOGIC_1164.ALL;
> use IEEE.STD_LOGIC_ARITH.ALL;
> use IEEE.STD_LOGIC_UNSIGNED.ALL;
> 
> entity ELIS_Statemachine is
>     Port ( Clock : in std_logic;
>            Reset : in std_logic;
>            StartStop : in std_logic;
>            ClockEnableOut : out std_logic;
>            ResetOut : out std_logic);
> end ELIS_Statemachine;
> 
> architecture Behavioral of ELIS_Statemachine is
>   type STATE_TYPE is (Clear,Zero,Start,Counting,Stop,Stopped);	
>   attribute ENUM_ENCODING: STRING;
>   attribute ENUM_ENCODING of STATE_TYPE: type is "000 101 010 001 011
> 100";
>   signal CS	: STATE_TYPE;
>   signal NS : STATE_TYPE;
> 
> begin
> 	   
>     SYNC_PROC: process (CLOCK, RESET)
>     begin
>        if (RESET='1') then
>               CS <= Clear;
>        elsif (CLOCK'event and CLOCK = '1') then
>             CS <= NS;
>        end if;
>     end process;
>  
>     COMB_PROC: process (CS, StartStop)
>     begin
>        case CS is
> 	      when clear => NS <= Zero;
> 		when Zero  => If StartStop = '1' then
> 		                NS <= Start;
> 				  else
> 				    NS <= Zero;
> 				  end if;
> 		when Start  => If StartStop = '0' then
> 		                NS <= Counting;
> 				  else
> 				    NS <= Start;
> 				  end if;
> 		when Counting  => If StartStop = '1' then
>       	                    NS <= Stop;
> 				      else
> 					  NS <= Counting;
>     				      end if;
> 		when Stop  => If StartStop = '0' then
> 		                NS <= Stopped;
> 				  else
> 				    NS <= Stop;
>     				  end if;
> 		when Stopped  => If StartStop = '1' then
> 		                   NS <= Zero;
> 				     else
> 				       NS <= Stopped;
>     				     end if;
>             when others =>	NS <= Clear;
>        end case;
>     end process;
>  
>     Sync_Output : process (Reset, Clock)
>     begin
> 	   if (RESET='1') then
>         ClockEnableOut <= '0';
> 		  ResetOut <= '1';
>       elsif (CLOCK'event and CLOCK = '1') then
>         case NS is
>    	     when clear =>     ClockEnableOut <= '0';
> 		                 ResetOut <= '1';
> 	     when Zero  =>     ClockEnableOut <= '0';
> 		                 ResetOut <= '0';
>  	     when Start  =>    ClockEnableOut <= '1';
> 		                 ResetOut <= '0';
> 	     when Counting  => ClockEnableOut <= '1';
> 		                 ResetOut <= '0';
> 	     when Stop  =>     ClockEnableOut <= '0';
> 		                 ResetOut <= '0';
> 	     when Stopped  =>  ClockEnableOut <= '0';
> 		                 ResetOut <= '0';
>            when others =>    ClockEnableOut <= '0';
> 		                 ResetOut <= '1';
>        end case;
>       end if;
>     end process;
> 
> end Behavioral;
> 
> 
> 
> Sourcecode of stmach.vhd :
> 
> LIBRARY ieee;
> USE ieee.std_logic_1164.all;
> 
> ENTITY STMACH IS
> 	PORT (CLK,RESET,strtstop: IN std_logic;
> 		clkout,rst : OUT std_logic);
> END;
> 
> ARCHITECTURE BEHAVIOR OF STMACH IS
> 	SIGNAL sreg : std_logic_vector (2 DOWNTO 0);
> 	SIGNAL next_sreg : std_logic_vector (2 DOWNTO 0);
> 	CONSTANT clear : std_logic_vector (2 DOWNTO 0) :="000";
> 	CONSTANT counting : std_logic_vector (2 DOWNTO 0) :="001";
> 	CONSTANT start : std_logic_vector (2 DOWNTO 0) :="010";
> 	CONSTANT stop : std_logic_vector (2 DOWNTO 0) :="011";
> 	CONSTANT stopped : std_logic_vector (2 DOWNTO 0) :="100";
> 	CONSTANT zero : std_logic_vector (2 DOWNTO 0) :="101";
> 
> BEGIN
> 	PROCESS (CLK, RESET, next_sreg)
> 	BEGIN
> 		IF ( RESET='1' ) THEN
> 			sreg <= clear;
> 		ELSIF CLK='1' AND CLK'event THEN
> 			sreg <= next_sreg;
> 		END IF;
> 	END PROCESS;
> 
> 	PROCESS (sreg,strtstop)
> 	BEGIN
> 		clkout <= '0'; rst <= '0'; 
> 
> 		next_sreg<=clear;
> 
> 		CASE sreg IS
> 			WHEN clear =>
> 				clkout<='0';
> 				rst<='1';
> 				IF  TRUE THEN
> 					next_sreg<=zero;
> 				 ELSE
> 					next_sreg<=clear;
> 				END IF;
> 			WHEN counting =>
> 				clkout<='1';
> 				rst<='0';
> 				IF  NOT ( (( strtstop='0' ) ) OR  (( strtstop='1' ) ) ) THEN
> 					next_sreg<=counting;
> 				END IF;
> 				IF ( strtstop='0' ) THEN
> 					next_sreg<=counting;
> 				END IF;
> 				IF ( strtstop='1' ) THEN
> 					next_sreg<=stop;
> 				END IF;
> 			WHEN start =>
> 				clkout<='1';
> 				rst<='0';
> 				IF  NOT ( (( strtstop='1' ) ) OR  (( strtstop='0' ) ) ) THEN
> 					next_sreg<=start;
> 				END IF;
> 				IF ( strtstop='1' ) THEN
> 					next_sreg<=start;
> 				END IF;
> 				IF ( strtstop='0' ) THEN
> 					next_sreg<=counting;
> 				END IF;
> 			WHEN stop =>
> 				clkout<='0';
> 				rst<='0';
> 				IF  NOT ( (( strtstop='1' ) ) OR  (( strtstop='0' ) ) ) THEN
> 					next_sreg<=stop;
> 				END IF;
> 				IF ( strtstop='1' ) THEN
> 					next_sreg<=stop;
> 				END IF;
> 				IF ( strtstop='0' ) THEN
> 					next_sreg<=stopped;
> 				END IF;
> 			WHEN stopped =>
> 				clkout<='0';
> 				rst<='0';
> 				IF  NOT ( (( strtstop='0' ) ) OR  (( strtstop='1' ) ) ) THEN
> 					next_sreg<=stopped;
> 				END IF;
> 				IF ( strtstop='0' ) THEN
> 					next_sreg<=stopped;
> 				END IF;
> 				IF ( strtstop='1' ) THEN
> 					next_sreg<=start;
> 				END IF;
> 			WHEN zero =>
> 				clkout<='0';
> 				rst<='0';
> 				IF  NOT ( (( strtstop='0' ) ) OR  (( strtstop='1' ) ) ) THEN
> 					next_sreg<=zero;
> 				END IF;
> 				IF ( strtstop='0' ) THEN
> 					next_sreg<=zero;
> 				END IF;
> 				IF ( strtstop='1' ) THEN
> 					next_sreg<=start;
> 				END IF;
> 			WHEN OTHERS =>
> 		END CASE;
> 	END PROCESS;
> END BEHAVIOR;


Article: 58476
Subject: Re: Where do I find model sim xe starter download?
From: "Yttrium" <Yttrium@pandora.be>
Date: Thu, 24 Jul 2003 16:25:31 GMT
Links: << >>  << T >>  << A >>
http://www.xilinx.com/xlnx/xil_prodcat_landingpage.jsp?title=ISE+WebPack

"Theron Hicks" <hicksthe@egr.msu.edu> wrote in message
news:bfosm6$1bh8$1@msunews.cl.msu.edu...
> Help,
>     I am looking for the free modelsim simulator and I cannot seem to find
> the link for it in the Xilinx web site.  Where is it?
> Theron Hicks
>
>



Article: 58477
Subject: Re: XST fails to recognize FSM with registered outputs
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Thu, 24 Jul 2003 09:53:43 -0700
Links: << >>  << T >>  << A >>


E. Backhus wrote:

> While my coding style produces a register and some feedback logic
> around it, for the original code (Produced by StateCAD) XST inferes a
> FSM and applies all optimizations on it.

Did you see any difference in resource usage
for the cases of XST recognizing it or not?

There isn't really any primitive state machine cell to map to anyway.

  -- Mike Treseler


Article: 58478
Subject: Re: Pricing question....
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 24 Jul 2003 10:19:59 -0700
Links: << >>  << T >>  << A >>
Stifler, except for your insulting tone, you say the same as I said: 
Contact a salesperson.
Peter Alfke, engineer.

Stifler wrote:
> 
> Petey,
> 
> I am curious. Are you sales? Are you Marketing? Are you Applications?
> Why are you vendors even on this board? Who believes all of your spew?
> 
> Your answer was a non answer. Contact your sales person. Oh thank you
> so much for that piece of such valuable information.
> 
> FPGAs are expensive. They are very complicated products that demand a
> high premium. Especially ones like V2 pro. The part has up to 4 PPCs,
> multiple 3.125 rocket IO, and a huge amount of ram and logic. It's
> state of the art chip technology. Do you think it is not worth $1500?
> 
> Pricing goes by volume and time. If you buy 10 per year you will never
> get what you are talking about. It's all about how important you are,
> how many you buy, and what you can negotiate. Time is a factor, but if
> you are low volume you will never get the best prices.
> 
> A sales person will just lie to you to get the socket. That's their
> job. Once they have the socket they have you in their wallet. As if
> you will design it out once you put it on the board.
> 
> My advice, get the deal in writing. Decide what you need the pricing
> to be and make them sign up for your proposal. Negotiate. It's the
> American way. Be a tough negotiator. They are in the driver's seat
> though. The technology is hot.
> 
> If you are Cisco you will get the best price. It goes downhill from
> there.
> 
> Peter Alfke <peter@xilinx.com> wrote in message news:<3F1F1F1A.C5C50F9E@xilinx.com>...
> > Your question can best be answered by a Xilinx salesperson, or most
> > likely a Sales Representative. If they cannot get you the answer
> > dirctly, they contact the factory.
> > They will love to talk to you and give you a quote with "budgetary
> > figures". They really are your friend, because they have a vested
> > interest to make you succeed. That is the only way they will get paid.
> > Do you have such a sales contact?
> >
> > Peter Alfke, Xilinx Applications
> > ================================
> > MS wrote:
> > >
> > > Hi,
> > > So we are looking to implement some functionality that we have done in
> > > NPUs in the past into a Xilinx Virtex2Pro family (small space and less
> > > power).
> > >
> > > These parts are quite expensive right now (up to $1500 a piece).  Our
> > > build timeframe is starting next year, carrying out into 2006/2007.
> > > When you add up the cost of product- the budget is nearly consumed
> > > completely by the FPGAs.
> > >
> > > The question is how much do you usually expect FPGA prices to fall in
> > > a given year.  For example, would a guess of a 15% drop in the first
> > > year followed by a 30% fall in the second year be a good stab?  20% a
> > > year?  I just need to fill out some numbers to make some bean counter
> > > happy.  Anyone take a look at what has historical been the price
> > > drops?
> > >
> > > Thanks,
> > > M Scott

Article: 58479
Subject: Re: FPGA Editor
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Thu, 24 Jul 2003 10:37:46 -0700
Links: << >>  << T >>  << A >>
Martin Euredjian wrote:

> I've found that meeting basic timing constraints (like PERIOD) does not
> guarantee that good logic (meaning that the HDL is good) will work.  That,
> BTW, to me, is one of the most frustrating aspects of FPGA's:  good code !=
> working device.

If you mean that the synthesis estimate of fmax
is sometimes wildly optimistic, then I agree with you.

If you mean that the device fails after meeting post-route
fmax then there is either a logical problem (testbench coverage)
or an unsynchronized input or output.


  -- Mike Treseler


Article: 58480
Subject: Re: FPGA Editor
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 24 Jul 2003 13:47:44 -0400
Links: << >>  << T >>  << A >>
Eric Pearson wrote:
> 
> Hi Martin
> 
> "Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message
> news:W7jTa.279$NK6.51@newssvr24.news.prodigy.com...
> >
> > I've found that meeting basic timing constraints (like PERIOD) does not
> > guarantee that good logic (meaning that the HDL is good) will work.  That,
> > BTW, to me, is one of the most frustrating aspects of FPGA's:  good code
> !=
> > working device.
> >
> 
> It must be frustrating however:
> 
> Proven board + Proven tools + Synchronous Design +
> Good Code (functionally correct) + Static Timing Closure =>  working device.
> 
> If I had a block which works sometimes, and then does'nt on the next route,
> and all timing constraints were met, I would have to ask if my design is
> 100% synchronous, and if so, what makes me believe that my code is good.

I guess I missed the post from Martin.  I don't understand why anyone
would say that a "good HDL" design that meets the timing constraints
does not necessarily work in an FPGA.  If your HDL functionally
simulates correctly and the timing analysis says you meet the timing
constraints and the design does not work, then this can mean only one
thing... you did not do your job correctly in designing the HDL, the
simulation or the timing constraints.  

I will agree that it is not easy to fully test a design in simulation
and it is not easy to design correct timing constraints.  There are
formal techniques to show that your simulation at least provides
coverage of the design.  But it is very hard to verify that your timing
constraints are complete and accurate.  This is one part of the job that
AFAIK has no method of verification other than testing the chip over
temperature and voltage.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 58481
Subject: Buying Xilinx Platform Flash PROM
From: "..:: Gabster ::.." <gabsterblue@hotmail.com>
Date: Thu, 24 Jul 2003 13:56:49 -0400
Links: << >>  << T >>  << A >>
Hi,

    I'm having a harding time buying a few XCF02S PROM to prototype my
design. Is there anyone out there who succesfully bought only a few (2-3) of
these IC's.

thanks,
Gabriel



Article: 58482
Subject: Re: Pricing question....
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Thu, 24 Jul 2003 11:02:12 -0700
Links: << >>  << T >>  << A >>
Stifler wrote:
> 
> I am curious. Are you sales? Are you Marketing? Are you Applications?
> Why are you vendors even on this board? Who believes all of your spew?

I do.
I am not using his brand at the moment,
but I always read what Peter Alfke has to say
because more often than not, I learn something.

> A sales person will just lie to you to get the socket. That's their
> job. Once they have the socket they have you in their wallet. As if
> you will design it out once you put it on the board.

I guess that depends on what kind of relationship
you have with your distribution and sales guys.


        -- Mike Treseler


Article: 58483
Subject: Re: FPGA Editor
From: Allan Herriman <allan_herriman.hates.spam@agilent.com>
Date: Fri, 25 Jul 2003 04:11:54 +1000
Links: << >>  << T >>  << A >>
On Thu, 24 Jul 2003 13:47:44 -0400, rickman <spamgoeshere4@yahoo.com>
wrote:

>Eric Pearson wrote:
>> 
>> Hi Martin
>> 
>> "Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message
>> news:W7jTa.279$NK6.51@newssvr24.news.prodigy.com...
>> >
>> > I've found that meeting basic timing constraints (like PERIOD) does not
>> > guarantee that good logic (meaning that the HDL is good) will work.  That,
>> > BTW, to me, is one of the most frustrating aspects of FPGA's:  good code
>> !=
>> > working device.
>> >
>> 
>> It must be frustrating however:
>> 
>> Proven board + Proven tools + Synchronous Design +
>> Good Code (functionally correct) + Static Timing Closure =>  working device.
>> 
>> If I had a block which works sometimes, and then does'nt on the next route,
>> and all timing constraints were met, I would have to ask if my design is
>> 100% synchronous, and if so, what makes me believe that my code is good.
>
>I guess I missed the post from Martin.  I don't understand why anyone
>would say that a "good HDL" design that meets the timing constraints
>does not necessarily work in an FPGA.  If your HDL functionally
>simulates correctly and the timing analysis says you meet the timing
>constraints and the design does not work, then this can mean only one
>thing... you did not do your job correctly in designing the HDL, the
>simulation or the timing constraints.  

We have done "difficult" high speed designs with early silicon, and
sometimes have found that there are other causes:

- overly optimistic speed files.
- ES silicon bugs (or "features", if they're documented).
- (individual) faulty parts.

>I will agree that it is not easy to fully test a design in simulation
>and it is not easy to design correct timing constraints.  There are
>formal techniques to show that your simulation at least provides
>coverage of the design.  But it is very hard to verify that your timing
>constraints are complete and accurate.  This is one part of the job that
>AFAIK has no method of verification other than testing the chip over
>temperature and voltage.  

Regards,
Allan.

Article: 58484
Subject: Re: Pricing question....
From: Andrew Paule <lsboogy@qwest.net>
Date: Thu, 24 Jul 2003 13:24:56 -0500
Links: << >>  << T >>  << A >>
Hi all:

I'm just an engineer - in no way associated with any of the producers of 
the products up here.  The only thing I would like to say is that it's 
good that the people like Pete are up here - he's an app (maybe more - 
he has designed some pretty good stuff) engineer who actually know what 
he's talking about.  I use parts from the companies that have apps 
people up here, and from those that are not present. All technologies 
are double edged swords - good points and bad.  Pricing questions ARE 
best left to sales people and your buyers.  Don't get on those who are 
trying to make our lives easier.

Andrew

Peter Alfke wrote:

>Stifler, except for your insulting tone, you say the same as I said: 
>Contact a salesperson.
>Peter Alfke, engineer.
>
>Stifler wrote:
>  
>
>>Petey,
>>
>>I am curious. Are you sales? Are you Marketing? Are you Applications?
>>Why are you vendors even on this board? Who believes all of your spew?
>>
>>Your answer was a non answer. Contact your sales person. Oh thank you
>>so much for that piece of such valuable information.
>>
>>FPGAs are expensive. They are very complicated products that demand a
>>high premium. Especially ones like V2 pro. The part has up to 4 PPCs,
>>multiple 3.125 rocket IO, and a huge amount of ram and logic. It's
>>state of the art chip technology. Do you think it is not worth $1500?
>>
>>Pricing goes by volume and time. If you buy 10 per year you will never
>>get what you are talking about. It's all about how important you are,
>>how many you buy, and what you can negotiate. Time is a factor, but if
>>you are low volume you will never get the best prices.
>>
>>A sales person will just lie to you to get the socket. That's their
>>job. Once they have the socket they have you in their wallet. As if
>>you will design it out once you put it on the board.
>>
>>My advice, get the deal in writing. Decide what you need the pricing
>>to be and make them sign up for your proposal. Negotiate. It's the
>>American way. Be a tough negotiator. They are in the driver's seat
>>though. The technology is hot.
>>
>>If you are Cisco you will get the best price. It goes downhill from
>>there.
>>
>>Peter Alfke <peter@xilinx.com> wrote in message news:<3F1F1F1A.C5C50F9E@xilinx.com>...
>>    
>>
>>>Your question can best be answered by a Xilinx salesperson, or most
>>>likely a Sales Representative. If they cannot get you the answer
>>>dirctly, they contact the factory.
>>>They will love to talk to you and give you a quote with "budgetary
>>>figures". They really are your friend, because they have a vested
>>>interest to make you succeed. That is the only way they will get paid.
>>>Do you have such a sales contact?
>>>
>>>Peter Alfke, Xilinx Applications
>>>================================
>>>MS wrote:
>>>      
>>>
>>>>Hi,
>>>>So we are looking to implement some functionality that we have done in
>>>>NPUs in the past into a Xilinx Virtex2Pro family (small space and less
>>>>power).
>>>>
>>>>These parts are quite expensive right now (up to $1500 a piece).  Our
>>>>build timeframe is starting next year, carrying out into 2006/2007.
>>>>When you add up the cost of product- the budget is nearly consumed
>>>>completely by the FPGAs.
>>>>
>>>>The question is how much do you usually expect FPGA prices to fall in
>>>>a given year.  For example, would a guess of a 15% drop in the first
>>>>year followed by a 30% fall in the second year be a good stab?  20% a
>>>>year?  I just need to fill out some numbers to make some bean counter
>>>>happy.  Anyone take a look at what has historical been the price
>>>>drops?
>>>>
>>>>Thanks,
>>>>M Scott
>>>>        
>>>>


Article: 58485
Subject: Re: FPGA Editor
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Thu, 24 Jul 2003 18:35:25 GMT
Links: << >>  << T >>  << A >>
Rick and Eric,

> Eric Pearson wrote:
> > Proven board + Proven tools + Synchronous Design +
> > Good Code (functionally correct) + Static Timing Closure =>  working
device.
> >
> > If I had a block which works sometimes, and then does'nt on the next
route,
> > and all timing constraints were met, I would have to ask if my design is
> > 100% synchronous, and if so, what makes me believe that my code is good.

> Rick Collins wrote:
> I guess I missed the post from Martin.  I don't understand why anyone
> would say that a "good HDL" design that meets the timing constraints
> does not necessarily work in an FPGA.  If your HDL functionally
> simulates correctly and the timing analysis says you meet the timing
> constraints and the design does not work, then this can mean only one
> thing... you did not do your job correctly in designing the HDL, the
> simulation or the timing constraints.
>
> I will agree that it is not easy to fully test a design in simulation
> and it is not easy to design correct timing constraints.  There are
> formal techniques to show that your simulation at least provides
> coverage of the design.  But it is very hard to verify that your timing
> constraints are complete and accurate.  This is one part of the job that
> AFAIK has no method of verification other than testing the chip over
> temperature and voltage.


I might be missing some of the posts because pacbell/sbc usenet servers have
been going through a "thing" for the last few weeks.  They are in serious
need of an exorcism.

Anyhow.  I'll give you a specific example here.  I wrote a SDRAM controller
from scratch.  Burst mode access only.  Nothing fancy (no command
pipelining, etc.).  I used an eight-bit register for a burst counter.  The
counter would be cleared upon entering the read or write command (right out
of the idle state).  During the actual burst portion of the command the
counter is incremented (+1) and compared to the appropriate terminal count
(say, 63).  So, the relevant portions of the code looked like this:
...
burst_counter <= 0;
...
burst_counter <= burst_counter + 1;
...
if(burst_counter == BURST_LENGTH)begin
...

Pretty basic stuff.

That worked very nicely on an XC2V1000 @ 133MHz.  I should note that the
only timing constraint I defined was period @ 7.5188ns.

Later on I decided that it would be better to have variable burst length (my
current app doesn't need it but I wanted to re-use the module in the
future).  It made more sense to preset the burst_counter to BURST_LENGTH
upon leaving idle and then check for zero to terminate.  The above HDL
became:

...
burst_counter <= BURST_LENGTH;
...
burst_counter <= burst_counter - 1;
...
if(burst_counter == 0)begin
...

All timing constraints for the design were met, but this did not work.
Again, the only thing I did was change from an up to a down counter and
modify the terminal condition.

In looking at the floorplanner I could see that the sdram controller logic
was all over the place.  Adding an area constraint forced the logic into a
tighter space and it all worked fine.

This is what I refer to when I say "good HDL".  The logic is good.  There's
absolutely nothing wrong with the HDL.  The problem is in the implementation
of said HDL within the chip.  So, from my vantage point, you can have
perfectly good HDL that does not produce a working design.  Good HDL alone
does not fully describe the working version of the design.

Perhaps I don't fully understand the mechanism.  I told the tools that the
module is clocked at 133MHz.  The tools said that timing looked good after
P&R.  If there were any timing issues (which I obviously had) why didn't it
report them?  Both sdram controller versions had perfectly good HDL that
simulated with exactly the same results.

More than eager to learn...

Thanks,


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"









Article: 58486
Subject: Re: FPGA Editor
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Thu, 24 Jul 2003 11:45:51 -0700
Links: << >>  << T >>  << A >>


Martin Euredjian wrote:

> All timing constraints for the design were met, but this did not work.
> Again, the only thing I did was change from an up to a down counter and
> modify the terminal condition.

Maybe your outputs were not registered,
and thus not covered by the fmax constraint.



  -- Mike Treseler


Article: 58487
Subject: Re: Pricing question....
From: "Peter C. Wallace" <pcw@freeby.mesanet.com>
Date: Thu, 24 Jul 2003 12:48:22 -0700
Links: << >>  << T >>  << A >>
On Wed, 23 Jul 2003 22:50:02 -0700, Stifler wrote:

> Petey,
> 
> I am curious. Are you sales? Are you Marketing? Are you Applications?
> Why are you vendors even on this board? Who believes all of your spew?
> 

I'm certainly glad that vendors are on this newsqroup. They are helpful,
polite, and provide lots of useful information, a model that you might
aspire to...

PCW

Article: 58488
Subject: Should I use ABEL?
From: Chris Carlen <crcarle@BOGUS.sandia.gov>
Date: Thu, 24 Jul 2003 12:57:31 -0700
Links: << >>  << T >>  << A >>
Hi:

I have read a little about ABEL, and it seems simpler than VHDL and 
Verilog.  I need to learn an HDL quickly so I want to use the easiest 
one, for starters.

I need to design relatively simple logic, usually just combinatorial 
glue logic, but also some asynchronous logic.

I wonder if ABELs simplicity might make it unable to express 
asynchronous logic well, in which case I might be better off with a more 
complex language.

An example of a more complex project that I might be facing, is to 
implement a triggered 16-bit counter.  An asynchronous trigger signal 
will have to reset the counter, and then initiate counting.  I picture 
using a fast clock of 10-20MHz to synchronize the async trigger, and 
reset the clock.  A slow count clock of about 1MHz will then clock the 
counter.

I have tired of trying to use Xilinx ECS schematic editor after 
implementing a modulo-40 Johnson counter in that just for fun.  Ouch!

What language would you recommend?

Thanks.


-- 
_______________________________________________________________________
Christopher R. Carlen
Principal Laser/Optical Technologist
Sandia National Laboratories CA USA
crcarle@sandia.gov -- NOTE: Remove "BOGUS" from email address to reply.


Article: 58489
Subject: Re: Should I use ABEL?
From: Andrew Paule <lsboogy@qwest.net>
Date: Thu, 24 Jul 2003 15:14:19 -0500
Links: << >>  << T >>  << A >>
Hi Chris -

don't do it  - learning ABEL is a little like learning FORTran.  Verilog 
is my choice, and if you need help, there are many of us who do it for 
fun and mentoring.  It's relatively easy for simple projects, and gets 
you away from vendor specific tools.  VHDL is another fairly easy 
language, and it seems to be hanging around well.  Either of these is 
becoming sort of like C (verilog and C are easy to transport and 
interface hardware/software designs, as the basic structure usage is 
very similar).

Andrew

Chris Carlen wrote:

> Hi:
>
> I have read a little about ABEL, and it seems simpler than VHDL and 
> Verilog.  I need to learn an HDL quickly so I want to use the easiest 
> one, for starters.
>
> I need to design relatively simple logic, usually just combinatorial 
> glue logic, but also some asynchronous logic.
>
> I wonder if ABELs simplicity might make it unable to express 
> asynchronous logic well, in which case I might be better off with a 
> more complex language.
>
> An example of a more complex project that I might be facing, is to 
> implement a triggered 16-bit counter.  An asynchronous trigger signal 
> will have to reset the counter, and then initiate counting.  I picture 
> using a fast clock of 10-20MHz to synchronize the async trigger, and 
> reset the clock.  A slow count clock of about 1MHz will then clock the 
> counter.
>
> I have tired of trying to use Xilinx ECS schematic editor after 
> implementing a modulo-40 Johnson counter in that just for fun.  Ouch!
>
> What language would you recommend?
>
> Thanks.
>
>


Article: 58490
Subject: Re: Should I use ABEL?
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Thu, 24 Jul 2003 13:25:53 -0700
Links: << >>  << T >>  << A >>
Chris Carlen wrote:

> I have read a little about ABEL, and it seems simpler than VHDL and 
> Verilog.  I need to learn an HDL quickly so I want to use the easiest 
> one, for starters.

ABEL is moribund.

If you are in a hurry, use schematics.

> I have tired of trying to use Xilinx ECS schematic editor after 
> implementing a modulo-40 Johnson counter in that just for fun.  Ouch!

If you can tolerate an Altera device, Quartus has a nice schematic editor.

> What language would you recommend?

None. Consider waiting until you are not in a hurry.

       --Mike Treseler


Article: 58491
Subject: Re: FPGA Editor
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Thu, 24 Jul 2003 20:30:57 GMT
Links: << >>  << T >>  << A >>
"Mike Treseler" <mike.treseler@flukenetworks.com> wrote:

> > All timing constraints for the design were met, but this did not work.
> > Again, the only thing I did was change from an up to a down counter and
> > modify the terminal condition.
>
> Maybe your outputs were not registered,
> and thus not covered by the fmax constraint.

Nope.  They are registered.  Also, the flip-flops are located in the IOB's.
Verified using FPGA Editor.  Code snippet below.

...
// synthesis attribute IOB of SDRAM_DQM is TRUE;
// synthesis attribute IOB of data_to_sdram is TRUE;
// synthesis attribute IOB of data_from_sdram is TRUE;
...

// Tri-state the bus as needed, otherwise output the
// data in the IOB flip-flop
//
assign SDRAM_DQ[47:0] = tristate ? 48'bz : data_to_sdram[47:0];
assign DATA_OUT[47:0] = data_from_sdram[47:0];

// Register outgoing data.
//
always @ (posedge SDRAM_CLK_IN) begin
 if(SDRAM_WRITING)
  data_to_sdram[47:0]  <= DATA_IN[47:0];
end

// Register incoming data.
//
always @ (posedge SDRAM_CLK_IN) begin
 if(SDRAM_READING)
  data_from_sdram[47:0] <= SDRAM_DQ[47:0];
end


"DATA_IN" and "DATA_OUT" are the module I/O.  They are both defined as
"wire".  I suppose I could re-define them as "reg" and add one clock of
delay to the I/O.  Is this my mistake?  I don't see how this would be
affected by changing my burst counter from an up counter to a down counter
... but I'll go with the flow.

Thanks,


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"











Article: 58492
Subject: Re: Active Probe
From: Bassman59a@yahoo.com (Andy Peters)
Date: 24 Jul 2003 13:31:02 -0700
Links: << >>  << T >>  << A >>
"Basuki Endah Priyanto" <EBEPriyanto@ntu.edu.sg> wrote in message news:<N8auEQZUDHA.3356@exchnews1.main.ntu.edu.sg>...
> Dear all,
> 
> Have you ever measured the signal level of your FPGA pin out using
> Oscilloscope ?

Yes -- it's the second thing I do when I'm bringing up a new board for
the first time.  The first thing, of course, is to put a voltmeter on
each of the power supplies.

> At the clock speed of 50 MHz, I observed the signal is destroyed. The
> oscilloscope sales guy pretends that I need to use active probe which is
> quite expensive.
> 
> He said it was a circuit loading issues.
> 
> Is there any such away to overcome this problem without buying the
> active probe ?

OK, what's your 'scope's bandwidth?  What's your probe's bandwidth? 
You can't look at a 50 MHz clock signal on a 100 MHz 'scope or with a
100 MHZ probe and expect to see anything other than a cruddy sine
wave.

Also, what's your probe's ground connection like?  Is it a six-inch
piece of wire?  Or are you making a very short connection to a nearby
ground?

Passive 10x probes are perfectly fine for what you're doing, as long
as they have sufficient bandwidth.  Sounds like the sales guy needs to
make another payment on the Porsche.

-a

Article: 58493
Subject: Re: FPGA Editor
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Thu, 24 Jul 2003 20:35:06 GMT
Links: << >>  << T >>  << A >>
"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote:

> "DATA_IN" and "DATA_OUT" are the module I/O.  They are both defined as
> "wire".  I suppose I could re-define them as "reg" and add one clock of
> delay to the I/O.  Is this my mistake?  I don't see how this would be
> affected by changing my burst counter from an up counter to a down counter
> ... but I'll go with the flow.

I should add that the modules reading and writing from sdram have fully
registered outputs on the same clock domain.


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"



Article: 58494
Subject: Re: Pricing question....
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Fri, 25 Jul 2003 09:16:41 +1200
Links: << >>  << T >>  << A >>
Tim Hogard wrote:
> 
> MS (wpiman@aol.com) wrote:
> : The question is how much do you usually expect FPGA prices to fall in
> : a given year.  For example, would a guess of a 15% drop in the first
> : year followed by a 30% fall in the second year be a good stab?  20% a
> : year?  I just need to fill out some numbers to make some bean counter
> : happy.  Anyone take a look at what has historical been the price
> : drops?
> Any number you pick will be a wild guess.
> 
> The long term cost to produce a popular chip is calculated by the
> size factored in with the failure rate.  The costs of the chip is
> the production cost plus R&D plus whatever else they throw in.  The
> early production cost of a new chip is related to its complexity,
> its process, its pin count, its R&D expense, its mareting expense,
> its tool development expenses adn a dew other factors.
> 
> If the chip is popular, then the R&D costs get spread over more
> chips.  As production gets better, the yield goes up and that makes
> it cheaper.  If there are problems with the chip (yield, marketing,
> bad tools, ugly web page, whatever), then the price may not go
> down much at all.
> 
> If you want to look at price graphs, look at Intel's PC processors
> and how they have dropped over time.  You will find different parts
> have different curves which are related to issues like the device
> being migrated to Cu or rumors of it over heating in laptops.  For
> any given FPGA, I expect you can find a price curve of an Intel CPU
> to match with a slight adjstment of scales.  You just have to bet
> on a chip thats going to go down and not stay level.  That is
> determined by other things you don't know and won't know until your
> far into production if its a new chip in a new family.
> 
> About all you can do is get budget numbers from the sales rep who
> will be relaying numbers that come from the guesses from the factory
> about how they hope things will go.

Correct, but you should also mention what a chip SELLS for is only
loosely related to COST of production.

Important additional factors are 
- What is the competition doing ?
- How much will the market stand ?
- Where the device fits into the product mix ?

-jg

Article: 58495
Subject: Re: Use ICAp iwth a soft IP core to decompress!!!!
From: symon_brewer@hotmail.com (Symon)
Date: 24 Jul 2003 15:18:40 -0700
Links: << >>  << T >>  << A >>
Hi Austin,
    On the other hand, I'm sure every one of those 150k designers
understands that compression ratios aren't guaranteed. It doesn't stop
us all using .zip files, does it? Just another tool in the designer's
armoury! Furthermore, Xilinx already offers bitstream compression on
an unused frames basis, so I don't really follow your argument that
Xilinx needs to give a compression guarantee before offering this
feature?
    So, doesn't the soft solution we're discussing here solve the
arguments against providing better compression? I'm sure loads of
folks would appreciate this feature. Why not get your marketing to ask
some of them? Also, why not try running WinZip on some of the many
sample designs you have, and let us know the results?
    I guess a cynic might say that because vendor A started offering
compression, the official vendor X stance is that it's not needed. Not
me though, I trust you guys have our best interests at heart!! ;-)
         All the best, Syms.

p.s. I chuckled at the 'wonderful downloading experience' bit! Over
the years my downloading experiences have often been somewhat less
than 'wonderful'! Frustrating, temperamental, even infuriating! I
guess I only remember the bad ones, I must admit things seem to have
improved recently. Must go smoke my 'Done Pipe'! ;-)

Austin Lesea <Austin.Lesea@xilinx.com> wrote in message news:<3F1FF59D.BE7CA90D@xilinx.com>...
> Ray,
> 
> We routinely get folks who say they can compress a particular bitfile by 5:1 or even 10:1.
> 
> Too bad that doesn't hold true for all bitfiles.
> 
> As I have said before, if there was a good way to guarantee compression, we would have done it years ago.
> 
> Let's see, we have ~150,000 bitstreams that are being developed right now at this moment.  Think about
> it:  to remain a quality supplier we have to make every one of those 150,000 designers have a wonderful
> (downloading) FPGA experience.  Just one flakey option bit in the bitgen, and the hotlines would meltdown.
> 
> Austin
>

Article: 58496
(removed)


Article: 58497
Subject: Re: Synplify syn_direct_enable doesn't work for me.
From: "Jim Robinson" <jim@synplicity.com>
Date: Thu, 24 Jul 2003 22:26:08 GMT
Links: << >>  << T >>  << A >>
Hi Symon,

Sorry that is missed that.  I was focused on the problem flop and
was not paying attention to the counter.

Since it appears that you have a work-around in place (toggle as
std_logic_vector),
I will shift my attention towards working with our development team to
diagnose the bug and schedule a fix.

My appologies for not providing you with a more useful work around.  Let me
know if you encounter any other difficulties.

Best Regards,
Jim Robinson



"Symon" <symon_brewer@hotmail.com> wrote in message
news:a28bc07f.0307230944.72673a2e@posting.google.com...
> Hi Jim,
>      Close, but no cigar! When I put the syn_keep on toggle, the FF
> data_int1 problem is cured! Sadly, Synplify then ignores my
> syn_direct_enable directive on the enable to the 4 counter FFs that
> make up toggle!
>      Any further thoughts? BTW, my interim work around is to make
> toggle a std_logic_vector and pick out bits in my code. This seems to
> work thus far.
>      Thanks for your help on this, it's much appreciated!
>                     cheers, Syms.
>
> p.s. This is what I added to the code:-
>
> attribute syn_keep: boolean;
> attribute syn_keep of toggle : signal is true;
>
>
> "Jim Robinson" <jim@synplicity.com> wrote in message
news:<mpjTa.27433$Nf.71843@sea-read.news.verio.net>...
> > Symon,
> >
> > You are using the syn_direct_enable directive correctly.
> > As you noticed, you achieved the desired behavior on the
> > data_int2 Flip Flop, but data_int1 FF was not correct.
> >
> > Synplify seems to be loosing the direct_enable when
> > it is evaluating the integer expression toggle=0 along with
> > the enable expression.
> >
> > It is possible to work around this problem by placing a "syn_keep"
> > directive on toggle.  The syn_keep directive creates an
> > optimization boundary and this prevents Synplify from optimizing
> > toggle together with enable and thus produces the results
> > you expected.  Your test case with my modifications follows
> > below.  I realize the RTL posted on this message is just a
> > test case, but I assume that a similar work around can be used
> > on your actual design.  If you need assistance getting this
> > to work on your design please do not hesitate to contact me
> > or any of our Corporate Application Engineers at
> > support@synplicity.com.
> >
> > Obviously this is a bug in Synplify and I have filed bug # 107936.
> > This will be fixed in a future release.  Please let me know if the
> > work around will solve your problem in the short term and
> > how urgently you require a fix to be incorporated into the tool.
> >
> > Best Regards,
> > Jim Robinson
> > jim@synplicity.com
> >
> >
> >
> >
> > library IEEE;
> > use IEEE.STD_LOGIC_1164.all;
> >
> > entity direct_enable_test is
> >   port (
> >     signal res_n            : in    std_logic;  -- General reset.
> >     signal clock            : in    std_logic;  -- clock 350MHz
> >     signal toggle_in        : in    integer range 0 to 15;  -- toggle
value
> >     signal data             : out   std_logic   -- data
> >     );
> > end direct_enable_test;
> >
> > architecture direct_enable_test_arch of direct_enable_test is
> >
> > signal enable   : std_logic;
> >
> > signal data_int1 : std_logic;
> > signal data_int2 : std_logic;
> > signal toggle   : integer range 0 to 15;  -- toggle value
> > attribute syn_direct_enable: boolean;
> > attribute syn_direct_enable of enable : signal is true;
> > attribute syn_keep: boolean;                         -- Workaround
> > attribute syn_keep of toggle : signal is true;       -- Workaround
> >
> > begin
> >
> >
> > data <= data_int1 or data_int2;
> >
> > process (res_n, clock)
> >   begin
> >     if (res_n = '0') then
> >       enable <= '0';
> >       toggle <= 0;
> >     elsif rising_edge (clock) then
> >       enable <= not enable;
> >       if enable = '1' then
> >         toggle <= (toggle + 1) mod 16;
> >       end if;
> >     end if;
> >   end process;
> >
> > process (res_n, clock)
> >   begin
> >     if (res_n = '0') then
> >       data_int1 <= '0';
> >     elsif rising_edge (clock) then
> >       if enable = '1' then
> >         if toggle = 0 then
> >           data_int1 <= not data_int1;
> >         end if;
> >       end if;
> >     end if;
> >   end process;
> >
> > process (res_n, clock)
> >   begin
> >     if (res_n = '0') then
> >       data_int2 <= '0';
> >     elsif rising_edge (clock) then
> >       if enable = '1' then
> >         if toggle_in = 0 then
> >           data_int2 <= not data_int2;
> >         end if;
> >       end if;
> >     end if;
> >   end process;
> >
> > end direct_enable_test_arch;



Article: 58498
Subject: temux
From: naderimisc@yahoo.com (Masoud Naderi)
Date: 24 Jul 2003 15:43:07 -0700
Links: << >>  << T >>  << A >>
Hi all,
I want to use PMC-Sierra chipset for my STM-1 card. Input to this card
is 16x16Mhz sync channels that comes from backplane. I can use
PMC_TEMUX chip(pm8316) to make 3xDS3 PDH channel and feed them to
PMC_SPECTRA chip (PM5342). But it seems using PMC_TEMUX chip is not
cost saving and not suitable for this design, because TEMUX can do
many things that wont use in this application. I think making DS3
signals from backplane signals (16Mhz) can be done easely in FPGA, so
bypassing TEMUX chip. It should be noted that single or multi E1
channels should be extraced from our output STM-1 signal (for example
from an ADM in SDH ring).
Please help me in this regard.
Regards.
M. Naderi

Article: 58499
Subject: VHDL predefined constants
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 24 Jul 2003 18:43:58 -0400
Links: << >>  << T >>  << A >>
In C programming the compiliers define constants for the date and time
and a lot of other things that are useful information to a program.  Do
VHDL synthesis packages do the same thing?  I am looking for an
indication of what tool is being used or what chip is being targeted so
that instantiated components can be tailored for the brand and family of
chip.  I am sure I am not the first person to think of this.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX



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