VHDL OPTIMIZATION FOR FPGA's: (Anyone have suggestions?) 
Author Message
 VHDL OPTIMIZATION FOR FPGA's: (Anyone have suggestions?)

Hello,

My name is Asher an I am looking for some advice on how I can decrease
the amount of space that my VHDL code takes up on my FPGA (Altera
EPF10K20RC240-4).  I here that using LPM or megafunctions is one way to
decrease the amount of space but I wanted to know exactly why and under
what conditions this was true.

According to Altera LPM (Library of Parameterized Modules) is a
technology-independent library of logic functions that are parameterized
to achieve scalability and adaptability.  I wondered, however, if this
also meant that the code was efficient and compact for any FPGA or just
a select few that were compatible with LPM.  I would really appreciate
any good comments or suggestions on this matter?

One other thing... Here is a page of code that I have written.  I wanted
to know if anyone could spot anything that could be done more
efficiently.  If you see something that doesn't look like it's the best
way to do it please offer a better technique.  

Anyhow, to summarize this code was made for the HEDS-9100 G00 /
HEDS-5500 G02 optical encoder made by HP. SEE:
http://www.*-*-*.com/
this code/device is .72 degrees with 500 counts per revolution (CPR) on
the codewheel.  The VHDL code posted below calculates the angle and
speed of rotation.  

You comments and suggestions on optimization are appreciated...

Best regards,

Quote:
>Asher<

<<=>>=<<=>>=<<=>><<=>>=<<=>>=<<=>>
 Asher C. Martin
 805 West Oregon Street
 Urbana, IL 61801-3825
 (217) 367-3877

  http://www.*-*-*.com/
 telnet://fermi.isdn.uiuc.edu
 ftp://feynman.isdn.uiuc.edu
<<=>>=<<=>>=<<=>><<=>>=<<=>>=<<=>>

-- //////////////////////////////////////////////////
-- //              by Asher C. Martin              //

-- //           http://www.*-*-*.com/          //
-- //    Robotics and Computer Vision Laboratory   //
-- //  University of Illinois at Urbana-Champaign  //
-- //////////////////////////////////////////////////

LIBRARY ieee;
USE ieee.std_logic_1164.all;
USE ieee.std_logic_arith.all;

ENTITY angle IS

-- All input and outputs from the FPGA are defined below.
PORT
(
ain     : IN    STD_LOGIC;      -- CHANNEL A FROM OPTICAL ENCODER
bin     : IN    STD_LOGIC;  -- CHANNEL B FROM OPTICAL ENCODER
reset_switch    : IN    STD_LOGIC;  -- IF ANGLE GETS OFFSET THEN RESET THIS
LINE    
clock   : IN    STD_LOGIC;  -- SYSTEM CLOCK
angle   : OUT   INTEGER RANGE 0 TO 500; -- Angle in Deg. = 360/500*angle
speed   : OUT   INTEGER RANGE 0 TO 127 := 0; -- Speed of rotation      
moved   : OUT   STD_LOGIC;  -- Moved goes high for each +.72 degree move
clockwise : OUT STD_LOGIC   -- Clockwise (CW) is high for CW rotation
);
END angle;

ARCHITECTURE angle_architecture OF angle IS
        SIGNAL  angle_counter   : INTEGER RANGE 0 to 500;
        SIGNAL  speed_counter   : INTEGER RANGE 0 to 127 := 0;
        SIGNAL  clock_counter   : INTEGER RANGE 0 to 1000000;
        SIGNAL  start                   : std_logic := '0';
        SIGNAL  aold                    : std_logic;
        SIGNAL  bold                    : std_logic;
        SIGNAL  dir                             : std_logic_vector(1 downto 0) := "00";
BEGIN

-- THE FOLLOWING CODE EVALUATES WHAT IS HAPPENING TO CHANNEL A
grab_data: PROCESS (clock)
begin
    if (reset_switch = '0') then
        angle_counter <= 0;
        speed_counter <= 0;
    elsif (clock'event and clock='1') then
        clock_counter <= clock_counter + 1;
        if (start = '1') then            
                if (clock_counter = 100000 and speed_counter > 0) then
                        speed_counter <= speed_counter - 1;
                        clock_counter <= 0;
                end if;
        else
                        speed_counter <= speed_counter;
                end if;
        dir  <= (bin xor bold) & (ain xor aold);
                aold <= ain;
                bold <= bin;
        case dir is
           when  "00" =>    --no change
                moved <= '0'; --leave cw output alone
           when  "01" =>    -- clockwise rotation
            start <= (start xor '1');
            if (start = '1') then
                speed_counter <= 127;
                clock_counter <= 0;
            end if;
                if (ain = '1' and bin = '0') then
                angle_counter <= angle_counter + 1;
                        moved <= '1';
                clockwise <= '1';
            end if;
                when "10" =>    --ccw rotation
            if (bin = '1' and ain = '0') then
                angle_counter <= angle_counter - 1;
                moved <= '1';
                clockwise <= '0';
            end if;
           when others =>   -- this is an error condition...either a bad
sensor or rotation is faster than clock
        end case;
    end if;
        --end if;
END PROCESS grab_data;

-- THE CURRENT ANGLE IS NOW LOCATED AT "ANGLE_OUTPUT"
        angle <= angle_counter;
        speed <= speed_counter;

END angle_architecture;



Sat, 26 Jan 2002 03:00:00 GMT  
 VHDL OPTIMIZATION FOR FPGA's: (Anyone have suggestions?)
One way is to use a good FPGA synthesis tool. The VHDL reader in Altera
is not a very "good" synthesis tool and usually ends up producing large
slow designs. Synopsys Design Compiler is not a good FPGA synthesis tool
either and again tends to produces large slow designs. Try using
Synopsys FPGA Express or Synplicity Synplify. I have used both. We own
FPGA Express. It tends to produce smaller faster designs than Design
Compiler (our ASIC synthesis tool). Other than that, you can use a
larger part. The larger the part, the more efficient place and route you
get (sometimes). You are concerned about area. Area and speed usually
trade off (larger area = higher speed than small area).

Good Luck,
PJ



Quote:
> Hello,

> My name is Asher an I am looking for some advice on how I can decrease
> the amount of space that my VHDL code takes up on my FPGA (Altera
> EPF10K20RC240-4).  I here that using LPM or megafunctions is one way
to
> decrease the amount of space but I wanted to know exactly why and
under
> what conditions this was true.

> According to Altera LPM (Library of Parameterized Modules) is a
> technology-independent library of logic functions that are
parameterized
> to achieve scalability and adaptability.  I wondered, however, if this
> also meant that the code was efficient and compact for any FPGA or
just
> a select few that were compatible with LPM.  I would really appreciate
> any good comments or suggestions on this matter?

> One other thing... Here is a page of code that I have written.  I
wanted
> to know if anyone could spot anything that could be done more
> efficiently.  If you see something that doesn't look like it's the
best
> way to do it please offer a better technique.

> Anyhow, to summarize this code was made for the HEDS-9100 G00 /
> HEDS-5500 G02 optical encoder made by HP. SEE:
> http://www.hp.com/HP-COMP/motion/heds9000.html The current accuracy of
> this code/device is .72 degrees with 500 counts per revolution (CPR)
on
> the codewheel.  The VHDL code posted below calculates the angle and
> speed of rotation.

> You comments and suggestions on optimization are appreciated...

> Best regards,

> >Asher<

> <<=>>=<<=>>=<<=>><<=>>=<<=>>=<<=>>
>  Asher C. Martin
>  805 West Oregon Street
>  Urbana, IL 61801-3825
>  (217) 367-3877

>  http://fermi.isdn.uiuc.edu
>  telnet://fermi.isdn.uiuc.edu
>  ftp://feynman.isdn.uiuc.edu
> <<=>>=<<=>>=<<=>><<=>>=<<=>>=<<=>>

> -- //////////////////////////////////////////////////
> -- //              by Asher C. Martin              //

> -- //          http://fermi.isdn.uiuc.edu          //
> -- //    Robotics and Computer Vision Laboratory   //
> -- //  University of Illinois at Urbana-Champaign  //
> -- //////////////////////////////////////////////////

> LIBRARY ieee;
> USE ieee.std_logic_1164.all;
> USE ieee.std_logic_arith.all;

> ENTITY angle IS

> -- All input and outputs from the FPGA are defined below.
> PORT
> (
> ain        : IN    STD_LOGIC;      -- CHANNEL A FROM OPTICAL ENCODER
> bin        : IN    STD_LOGIC;  -- CHANNEL B FROM OPTICAL ENCODER
> reset_switch       : IN    STD_LOGIC;  -- IF ANGLE GETS OFFSET THEN RESET
THIS
> LINE
> clock      : IN    STD_LOGIC;  -- SYSTEM CLOCK
> angle      : OUT   INTEGER RANGE 0 TO 500; -- Angle in Deg. = 360/500*angle
> speed      : OUT   INTEGER RANGE 0 TO 127 := 0; -- Speed of rotation
> moved      : OUT   STD_LOGIC;  -- Moved goes high for each +.72 degree move
> clockwise : OUT    STD_LOGIC   -- Clockwise (CW) is high for CW
rotation
> );
> END angle;

> ARCHITECTURE angle_architecture OF angle IS
>    SIGNAL  angle_counter   : INTEGER RANGE 0 to 500;
>    SIGNAL  speed_counter   : INTEGER RANGE 0 to 127 := 0;
>    SIGNAL  clock_counter   : INTEGER RANGE 0 to 1000000;
>    SIGNAL  start                   : std_logic := '0';
>    SIGNAL  aold                    : std_logic;
>    SIGNAL  bold                    : std_logic;
>    SIGNAL  dir                             : std_logic_vector(1
downto 0) := "00";
> BEGIN

> -- THE FOLLOWING CODE EVALUATES WHAT IS HAPPENING TO CHANNEL A
> grab_data: PROCESS (clock)
> begin
>     if (reset_switch = '0') then
>         angle_counter <= 0;
>         speed_counter <= 0;
>     elsif (clock'event and clock='1') then
>            clock_counter <= clock_counter + 1;
>            if (start = '1') then
>            if (clock_counter = 100000 and speed_counter > 0) then
>                    speed_counter <= speed_counter - 1;
>                    clock_counter <= 0;
>            end if;
>         else
>                    speed_counter <= speed_counter;
>            end if;
>         dir  <= (bin xor bold) & (ain xor aold);
>            aold <= ain;
>            bold <= bin;
>         case dir is
>            when  "00" =>    --no change
>                 moved <= '0'; --leave cw output alone
>            when  "01" =>    -- clockwise rotation
>             start <= (start xor '1');
>             if (start = '1') then
>                    speed_counter <= 127;
>                    clock_counter <= 0;
>             end if;
>                    if (ain = '1' and bin = '0') then
>                 angle_counter <= angle_counter + 1;
>                            moved <= '1';
>                 clockwise <= '1';
>             end if;
>                    when "10" =>    --ccw rotation
>             if (bin = '1' and ain = '0') then
>                 angle_counter <= angle_counter - 1;
>                 moved <= '1';
>                 clockwise <= '0';
>             end if;
>            when others =>   -- this is an error condition...either a
bad
> sensor or rotation is faster than clock
>         end case;
>     end if;
>    --end if;
> END PROCESS grab_data;

> -- THE CURRENT ANGLE IS NOW LOCATED AT "ANGLE_OUTPUT"
>    angle <= angle_counter;
>    speed <= speed_counter;

> END angle_architecture;

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.


Sat, 26 Jan 2002 03:00:00 GMT  
 VHDL OPTIMIZATION FOR FPGA's: (Anyone have suggestions?)
As a note, Synopsys DC is not an FPGA synthesis tool - that's why they have
FPGA Compiler for FPGAs.

Adam

Quote:

> One way is to use a good FPGA synthesis tool. The VHDL reader in Altera
> is not a very "good" synthesis tool and usually ends up producing large
> slow designs. Synopsys Design Compiler is not a good FPGA synthesis tool
> either and again tends to produces large slow designs. Try using
> Synopsys FPGA Express or Synplicity Synplify. I have used both. We own
> FPGA Express. It tends to produce smaller faster designs than Design
> Compiler (our ASIC synthesis tool). Other than that, you can use a
> larger part. The larger the part, the more efficient place and route you
> get (sometimes). You are concerned about area. Area and speed usually
> trade off (larger area = higher speed than small area).

> Good Luck,
> PJ



> > Hello,

> > My name is Asher an I am looking for some advice on how I can decrease
> > the amount of space that my VHDL code takes up on my FPGA (Altera
> > EPF10K20RC240-4).  I here that using LPM or megafunctions is one way
> to
> > decrease the amount of space but I wanted to know exactly why and
> under
> > what conditions this was true.

> > According to Altera LPM (Library of Parameterized Modules) is a
> > technology-independent library of logic functions that are
> parameterized
> > to achieve scalability and adaptability.  I wondered, however, if this
> > also meant that the code was efficient and compact for any FPGA or
> just
> > a select few that were compatible with LPM.  I would really appreciate
> > any good comments or suggestions on this matter?

> > One other thing... Here is a page of code that I have written.  I
> wanted
> > to know if anyone could spot anything that could be done more
> > efficiently.  If you see something that doesn't look like it's the
> best
> > way to do it please offer a better technique.

> > Anyhow, to summarize this code was made for the HEDS-9100 G00 /
> > HEDS-5500 G02 optical encoder made by HP. SEE:
> > http://www.hp.com/HP-COMP/motion/heds9000.html The current accuracy of
> > this code/device is .72 degrees with 500 counts per revolution (CPR)
> on
> > the codewheel.  The VHDL code posted below calculates the angle and
> > speed of rotation.

> > You comments and suggestions on optimization are appreciated...

> > Best regards,

> > >Asher<

> > <<=>>=<<=>>=<<=>><<=>>=<<=>>=<<=>>
> >  Asher C. Martin
> >  805 West Oregon Street
> >  Urbana, IL 61801-3825
> >  (217) 367-3877

> >  http://fermi.isdn.uiuc.edu
> >  telnet://fermi.isdn.uiuc.edu
> >  ftp://feynman.isdn.uiuc.edu
> > <<=>>=<<=>>=<<=>><<=>>=<<=>>=<<=>>

> > -- //////////////////////////////////////////////////
> > -- //              by Asher C. Martin              //

> > -- //          http://fermi.isdn.uiuc.edu          //
> > -- //    Robotics and Computer Vision Laboratory   //
> > -- //  University of Illinois at Urbana-Champaign  //
> > -- //////////////////////////////////////////////////

> > LIBRARY ieee;
> > USE ieee.std_logic_1164.all;
> > USE ieee.std_logic_arith.all;

> > ENTITY angle IS

> > -- All input and outputs from the FPGA are defined below.
> > PORT
> > (
> > ain   : IN    STD_LOGIC;      -- CHANNEL A FROM OPTICAL ENCODER
> > bin   : IN    STD_LOGIC;  -- CHANNEL B FROM OPTICAL ENCODER
> > reset_switch  : IN    STD_LOGIC;  -- IF ANGLE GETS OFFSET THEN RESET
> THIS
> > LINE
> > clock : IN    STD_LOGIC;  -- SYSTEM CLOCK
> > angle : OUT   INTEGER RANGE 0 TO 500; -- Angle in Deg. = 360/500*angle
> > speed : OUT   INTEGER RANGE 0 TO 127 := 0; -- Speed of rotation
> > moved : OUT   STD_LOGIC;  -- Moved goes high for each +.72 degree move
> > clockwise : OUT       STD_LOGIC   -- Clockwise (CW) is high for CW
> rotation
> > );
> > END angle;

> > ARCHITECTURE angle_architecture OF angle IS
> >       SIGNAL  angle_counter   : INTEGER RANGE 0 to 500;
> >       SIGNAL  speed_counter   : INTEGER RANGE 0 to 127 := 0;
> >       SIGNAL  clock_counter   : INTEGER RANGE 0 to 1000000;
> >       SIGNAL  start                   : std_logic := '0';
> >       SIGNAL  aold                    : std_logic;
> >       SIGNAL  bold                    : std_logic;
> >       SIGNAL  dir                             : std_logic_vector(1
> downto 0) := "00";
> > BEGIN

> > -- THE FOLLOWING CODE EVALUATES WHAT IS HAPPENING TO CHANNEL A
> > grab_data: PROCESS (clock)
> > begin
> >     if (reset_switch = '0') then
> >         angle_counter <= 0;
> >         speed_counter <= 0;
> >     elsif (clock'event and clock='1') then
> >       clock_counter <= clock_counter + 1;
> >       if (start = '1') then
> >               if (clock_counter = 100000 and speed_counter > 0) then
> >                       speed_counter <= speed_counter - 1;
> >                       clock_counter <= 0;
> >               end if;
> >         else
> >                       speed_counter <= speed_counter;
> >               end if;
> >         dir  <= (bin xor bold) & (ain xor aold);
> >               aold <= ain;
> >               bold <= bin;
> >         case dir is
> >            when  "00" =>    --no change
> >                 moved <= '0'; --leave cw output alone
> >            when  "01" =>    -- clockwise rotation
> >             start <= (start xor '1');
> >             if (start = '1') then
> >               speed_counter <= 127;
> >               clock_counter <= 0;
> >             end if;
> >               if (ain = '1' and bin = '0') then
> >                 angle_counter <= angle_counter + 1;
> >                       moved <= '1';
> >                 clockwise <= '1';
> >             end if;
> >               when "10" =>    --ccw rotation
> >             if (bin = '1' and ain = '0') then
> >                 angle_counter <= angle_counter - 1;
> >                 moved <= '1';
> >                 clockwise <= '0';
> >             end if;
> >            when others =>   -- this is an error condition...either a
> bad
> > sensor or rotation is faster than clock
> >         end case;
> >     end if;
> >       --end if;
> > END PROCESS grab_data;

> > -- THE CURRENT ANGLE IS NOW LOCATED AT "ANGLE_OUTPUT"
> >       angle <= angle_counter;
> >       speed <= speed_counter;

> > END angle_architecture;

> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.

--
"Sometimes I think the surest sign that there's intelligent life on
other planets is that none of it has tried to contact us."
                                      - Calvin, "Calvin and Hobbes"


Sat, 26 Jan 2002 03:00:00 GMT  
 VHDL OPTIMIZATION FOR FPGA's: (Anyone have suggestions?)

Quote:

> One way is to use a good FPGA synthesis tool. The VHDL reader in Altera
> is not a very "good" synthesis tool and usually ends up producing large
> slow designs. Synopsys Design Compiler is not a good FPGA synthesis tool
> either and again tends to produces large slow designs. Try using
> Synopsys FPGA Express or Synplicity Synplify.

Also might try Leonardo Spectrum.

http://www.synplicity.com/

http://www.exemplar.com/index.html

http://www.synopsys.com/products/fpga/fpga_express.html

Any of these three tools will produce better results than the default
VHDL complier in Max Plus Two.  I have used all three.

As for Asher's code, I notice one thing that might reduce design size.

        SIGNAL  clock_counter   : INTEGER RANGE 0 to 1000000;

I don't think that clock_counter can ever get larger than 100000.  The
SIGNAL declaration may require a larger register (and larger
incrementers and comparators).  I doubt (but have NOT tried) that any
tool is smart enough to notice this.

So I'd suggest you try changing clock_counter to a smaller range,
perhaps 0 to 131071?

--
Phil Hays
"Irritatingly,  science claims to set limits on what
we can do,  even in principle."   Carl Sagan



Sat, 26 Jan 2002 03:00:00 GMT  
 VHDL OPTIMIZATION FOR FPGA's: (Anyone have suggestions?)
Greetings,

Thanks for the advice... would anyone happen to know if LPM functions
are necessary to reduce the amount of space that VHDL takes up on an
FPGA?

Best regards,

Quote:
>Asher<

<<=>>=<<=>>=<<=>><<=>>=<<=>>=<<=>>
 Asher C. Martin
 805 West Oregon Street
 Urbana, IL 61801-3825
 (217) 367-3877

 http://fermi.isdn.uiuc.edu
 telnet://fermi.isdn.uiuc.edu
 ftp://feynman.isdn.uiuc.edu
<<=>>=<<=>>=<<=>><<=>>=<<=>>=<<=>>


Sun, 27 Jan 2002 03:00:00 GMT  
 VHDL OPTIMIZATION FOR FPGA's: (Anyone have suggestions?)
Depends on your coding style and how much floorplanning you are willing
to do.   The LPMs are "optimized" designs for the target FPGA
architecture, and they are often floorplanned too.  I put optimized in
quotes because more often than not, the optimization seems to be a
compromise between conflicting goals.  A faster design may take up more
resources than a slower one for example.  LPMs do allow someone less
familiar with the device architecture to get better performance/density
than he might otherwise.  However, LPMs come at a cost:  First, they are
a pain for simulation.  Second, the LPM boundaries are usually "hard" so
surrounding logic often won't get absorbed in optimization.  Most of the
LPM functions are pretty simple.  In schematic based designs, they can
hide details like carry chain (which can be confusing) implementation.  A
good synthesizer can generate the carry chain logic without resorting to
LPMs, so their usefulness is diminished.  I personally don't use the LPMs
much because with usually little effort I can meet or exceed the
performance and/or density of the LPMs without the associated headaches.

So the short answer is: No, you don't need to use LPMs to minimize area
or maximize performance, but you need to know the implementation that
will get you minimum area and how to write the VHDL to get that
implementation.  Generally speaking, if you write at an RTL level so that
the logic between each register is explicitly defined, you get pretty
close.  For xilinx, you may also have to go into the floorplanner to
layout the design to obtain the performance of the LPM.  In Altera, that
is less critical.

Quote:

> Greetings,

> Thanks for the advice... would anyone happen to know if LPM functions
> are necessary to reduce the amount of space that VHDL takes up on an
> FPGA?

> Best regards,

> >Asher<

> <<=>>=<<=>>=<<=>><<=>>=<<=>>=<<=>>
>  Asher C. Martin
>  805 West Oregon Street
>  Urbana, IL 61801-3825
>  (217) 367-3877

>  http://fermi.isdn.uiuc.edu
>  telnet://fermi.isdn.uiuc.edu
>  ftp://feynman.isdn.uiuc.edu
> <<=>>=<<=>>=<<=>><<=>>=<<=>>=<<=>>

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950

http://users.ids.net/~randraka


Sun, 27 Jan 2002 03:00:00 GMT  
 VHDL OPTIMIZATION FOR FPGA's: (Anyone have suggestions?)
LPM is written by AHDL not VHDL. If you are using LPM, your design is no
more VHDL desing.
Quote:

> Greetings,

> Thanks for the advice... would anyone happen to know if LPM functions
> are necessary to reduce the amount of space that VHDL takes up on an
> FPGA?

> Best regards,

> >Asher<

> <<=>>=<<=>>=<<=>><<=>>=<<=>>=<<=>>
>  Asher C. Martin
>  805 West Oregon Street
>  Urbana, IL 61801-3825
>  (217) 367-3877

>  http://fermi.isdn.uiuc.edu
>  telnet://fermi.isdn.uiuc.edu
>  ftp://feynman.isdn.uiuc.edu
> <<=>>=<<=>>=<<=>><<=>>=<<=>>=<<=>>



Sun, 03 Feb 2002 03:00:00 GMT  
 VHDL OPTIMIZATION FOR FPGA's: (Anyone have suggestions?)

Quote:

> LPM is written by AHDL not VHDL. If you are using LPM, your design is no
> more VHDL desing.

That was a "letter of the law" vs. "spirit of the law" reply. I am sure
the original poster appreciates your "helpful advice".

The question really was "is it necessary to use paramaterized functions"
to optimize a design in VHDL. Now we know that LPM is an Altera acronym
used with their AHDL language, but we also know that VHDL supports
generics to make parameterized components, and this is (probably) what
he was asking.

The answer to the original question is 'maybe'. Depends upon your
particular application, i.e. speed, size, functionality. I personally
have never needed hand crafted functions. But then again I generally do
medium speed control applications and not high speed data path stuff.

BTW, I am sure glad that US Actel support people aren't as "helpful" as
the Korean Actel team.

--
Brian C. Boorman
Harris RF Communications
Rochester, NY 14610

<Remove the XYZ. for valid address>



Sun, 03 Feb 2002 03:00:00 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. FPGA design services in VHDL and Verilog, FPGA to ASIC conversion

2. Synopsys FPGA compiler optimization ?

3. P5/P6 optimization suggestions needed

4. P5/P6 optimization suggestions needed

5. a small optimization suggestion

6. VHDL'87 to VHDL'93 upgrade

7. VHDL'87 vs VHDL'93

8. having trouble 'making' XF

9. Anyone else having trouble with GIFs?

10. anyone else in c.l.e. having

11. FPGA Express and 'wait until'

12. PLD's, FPGA's & VITAL

 

 
Powered by phpBB® Forum Software