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
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: 58476http://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
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 TreselerArticle: 58478
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 ScottArticle: 58479
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 TreselerArticle: 58480
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 FAXArticle: 58481
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
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: 58483On 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
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
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
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 TreselerArticle: 58487
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... PCWArticle: 58488
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
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
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"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
"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. -aArticle: 58493
"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
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 ? -jgArticle: 58495
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: 58496Hi 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
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. NaderiArticle: 58499
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:
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