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 149975

Article: 149975
Subject: Re: FPGA BOARD QUESTION
From: Gabor <gabor@alacron.com>
Date: Sat, 4 Dec 2010 12:20:02 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 4, 1:04=A0pm, rickman <gnu...@gmail.com> wrote:
> On Dec 3, 6:01 am, RealInfo <therighti...@gmail.com> wrote:
>
> > Hi all
> > I need to buy a FPGA evaluation board to practice my comeback
> > to the FPGA design with VHDL.
>
> > Can you offer me a board that will do that
> > =A0based on your experience ?
>
> > Thanks
>
> > EC
>
> Here is one that is pretty low cost... at least if you have the right
> computer to use it with.
>
> http://www.latticesemi.com/products/developmenthardware/developmentki...
>
> It is a small XP2 flash FPGA, about 5 or 6 kLUTs. =A0But that is plenty
> enough to get started. =A0It includes a 256 kB SPI flash and a 128 kB
> SRAM along with a serial port interface and the prerequisite LEDs,
> push buttons and dip switches. =A0One down side to this low priced kit
> is the lack of a real programming cable. =A0They give you a parallel
> port cable, no doubt an ancient over-stock left from the dot com
> bubble 10 years ago. =A0But if you still have a parallel port on your PC
> (they tell you a USB parallel adapter won't work) you might just get
> by with this $49 kit!
>
> One cool thing about a flash FPGA is that it will boot up with no
> other chips and no cable. =A0I find that pretty useful myself.
>
> Rick

I bought one of these at the introductory price of $29.99

It comes with a parallel cable and a serial cable.  My new computer
has neither
a parallel nor a serial port so I hooked it to my ancient Toshiba
Satellite 4600.
The kit is pretty minimal from an I/O standpoint.  There are just
enough LED's
(8) to make a miserable light show.  The demos with the kit were all
about
the Mico8 processor and using the Lattice Reveal analyzer.  However
there
is a connector with enough I/O's to possibly hook up something useful.

By the way, I know it's not as much fun as seeing a design come alive
in hardware, but you can get started with VHDL with no more than
a free software download from any major FPGA vendor and use
the castrated version of simulator that comes with it.

-- Gabor

Article: 149976
Subject: Re: Help for a embeded system with SPARTAN-6 project
From: eric <eric.dube.3@gmail.com>
Date: Sat, 4 Dec 2010 13:11:11 -0800 (PST)
Links: << >>  << T >>  << A >>
Thx for the replies,

@John Those board look nice unfortunately there also outside my price
range, because I currently unemployed witch suck for the money, but
also give me time to learn cool thing.

@Michael Kellett

I like your suggestion, I have already the basic VHDL skill from
university course, so I had already done the littles projects, the
trafic ligths, coffee machine, Simon memory game, barrel shifter,
floating point multiplier and more.

But I do like your MP3 decoder suggestion, I do remember it involve
huffman coding and inverse cosine transform, I just wonder if the
standard is open ?
I think I can code a fixed point implantation in Matlab first and then
code the decoder in VHDL, and why not add after  a JPEG codex to use
the LCD and the camera.

thx for the idea :)

Eric


On Dec 2, 3:32=A0am, "Michael Kellett" <nos...@nospam.com> wrote:
> "Thales2" <eric.dube.3@n_o_s_p_a_m.gmail.com> wrote in message
>
> news:HLCdnR2u8oF1HWvRnZ2dnUVZ_j2dnZ2d@giganews.com...
>
>
>
>
>
>
>
>
>
> > Hi,
>
> > I an new to FPGA develepement and I want to build a litte embeded syste=
m
> > using the SP601 SPARTAN-6, to develepod my VHDL,c++ and PCB skill. But =
I
> > dont kwon if my projet is realitical, so I seek input from experience
> > developer here, before I buy the stuff.
>
> > I am currently designing a dauterboard for the SP601 kit to the include
> > the
> > folowing periferals :
>
> > - tft LCDhttp://www.sparkfun.com/products/8335
> > - 1 or more CMOS camera like this one
> >http://www.sparkfun.com/products/8667
> > - an audio codex (to be chosen)
> > - SD card reade
>
> > As a first projet with this board. I would like to code in VHDL the LCD
> > and
> > camera controler and use the microblaze softcore to devepod in c++ a GU=
I
> > using the QT tools (http://qt.nokia.com/). So basically I want the user=
 to
> > be able to take a shot using the GUI control and display it to the LCD.
>
> > Latter I would like to implement function like music and video player a=
nd
> > maybe latter implement some cool computer vision processing using the
> > openCV library and dedicated FPGA hardware.
>
> > 1) Do this look possible to you ?
> > 2) is the microblaze core able to handle the QT and OpenCV lib ?
> > 3) any suggestion to help me get that project started ?
>
> > Thx for your inputs
>
> > Eric
>
> > ---------------------------------------
> > Posted throughhttp://www.FPGARelated.com
>
> As John said it's possible but it's much too ambitious for a first projec=
t
> to learn about FPGAs. You'll get bogged down with the softcore and the to=
uch
> screen etc which won't teach you much about FPGA or VHDL.
>
> Start with a much less complex design and a really cheap dev kit (Lattice
> have some real cheapos !).
>
> If you haven't done the traffic lights or 7 seg LCD controller in VHDL th=
en
> start with them.
>
> If you are past that stage and want a big FPGA challenge try the MP3 deco=
der
> in VHDL !
>
> (There may be more suitable projects in between but you'll get the idea -
> pick something which is 90% VHDL on the FPGA if it's VHDL you want to
> learn.)
>
> Michael Kellett


Article: 149977
Subject: Re: FSM single process...BIG question
From: Newman <newman5382@yahoo.com>
Date: Sat, 4 Dec 2010 13:22:27 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 3, 4:05=A0am, Thomas Stanka <usenet_nospam_va...@stanka-web.de>
wrote:
> > Yes code is very simple...I've already coded a version with 2 process a=
nd
> > unregistered output...but, to better
> > understand, I would like to discover if it is possible in one process..=
.
>
> > In general..better 1 process and registered outout or 2 process and cho=
ose
> > if un/register output???
>
> Why do you want to avoid the output register? Is it for latency or
> resource usage? Is there really no other sollution?
> I strongly suggest to register outputs whenever possible. For all
> other cases I tend to use concurrent signal assignments. Of course I
> use also combinatorical process in cases it would simplify concurrent
> statements (which is seldom the case)
>
> process (clk,rst)
> if reset =3D active then
> =A0 sig_a <=3D '0';
> elsif rising_edge(clk)
> =A0sig_a <=3D input_a;
> end if;
> end process;
>
> comb_out <=3D (sig_a xor input_a) when fsm_state=3Didle else '0';

Just to elaborate on Thomas Stanka's post...

Say that you've inherited a design that has a large FSM that had a
clocked process and the BRAM were from an old technology and
interfaced to the FSM with combinatorial inputs.  The new device has
registered BRAM inputs so you want to get rid of a pipeline delay in
the FSM but want to keep the changes to a minimum.

I went through the exercise with the example to see how messy it would
be.

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity state_test is

  port (
    clk     : in std_logic;
    reset   : in std_logic;
    txValid : in std_logic;
    txReady : in std_logic;
    dataIn  : in std_logic_vector(7 downto 0);

    tx_data_out : out std_logic_vector(7 downto 0)
    );

end state_test;

architecture behav of state_test is
  type state_typ is (TXD_IDLE, TXD_ACTIVE, TXD_END);

  signal act_txd_state               : state_typ :=3D TXD_IDLE;
  signal tx_data_next, tx_data : std_logic_vector(7 downto 0);

begin
  tx_data_out <=3D tx_data_next;

  tx_data_next <=3D
    "00000000" when reset =3D
'1'
else
    "01000000" when ((act_txd_state =3D TXD_IDLE) and (txValid =3D '1')
and (dataIn =3D "00000000"))  else
    "11000000" when ((act_txd_state =3D TXD_IDLE) and (txValid =3D '1')
and (dataIn /=3D "00000000")) else
    dataIn     when ((act_txd_state =3D
TXD_END))
else
    tx_data;

  sync_proc : process (clk, reset) is
  begin
    if (reset =3D '1') then
      act_txd_state <=3D TXD_IDLE;
      tx_data       <=3D (others =3D> '0');
    elsif (clk'event and clk =3D '1') then
      tx_data <=3D tx_data_next;

      case act_txd_state is

        when TXD_IDLE =3D>
          if (txValid =3D '1') then
            act_txd_state <=3D TXD_ACTIVE;
          end if;


        when TXD_ACTIVE =3D>
          if (txReady =3D '1') then
            act_txd_state <=3D TXD_END;
          end if;


        when TXD_END =3D>
          if (txValid =3D '0') then
            act_txd_state <=3D TXD_IDLE;
          end if;
      end case;

    end if;
  end process sync_proc;
end behav;

Article: 149978
Subject: Concurrent Logic Timing
From: rickman <gnuarm@gmail.com>
Date: Sat, 4 Dec 2010 14:32:53 -0800 (PST)
Links: << >>  << T >>  << A >>
I suppose this is something that you need to expect, but I just have
never come across this before.  I have some concurrent logic equations
using integers where one input common to two assignments changes and
because one gets updated before the other, one is set to a value that
is outside the range of the integer and flags an error in
simulation.

C <= B - A * stuff;
D <= A + C;  -- A changes and puts D outside of its range until C is
updated

In the real world, this is not really an issue since all sorts of
intermediate states are expected when doing arithmetic.  But VHDL
doesn't seem to accommodate this well.  The only way I can think of to
fix this, without changing the logic, is to do these calculations
inside a combinatorial process using variables.  Then I can control
the sequence of updates explicitly.

The only other thing I can think is to assign A to A' and use A' in
place of A in the assignment for D.  That may still allow an error,
but if A'' is used, then there will be two delta delays in D
assignment path.  However, if C grows because A has shrunk, then that
could cause the same sort of out of bounds error on D.

Is there another way make this work that isn't so cumbersome?

Rick

Article: 149979
Subject: Re: Concurrent Logic Timing
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sat, 4 Dec 2010 23:29:44 +0000 (UTC)
Links: << >>  << T >>  << A >>
In comp.arch.fpga rickman <gnuarm@gmail.com> wrote:

> I suppose this is something that you need to expect, but I just have
> never come across this before.  I have some concurrent logic equations
> using integers where one input common to two assignments changes and
> because one gets updated before the other, one is set to a value that
> is outside the range of the integer and flags an error in
> simulation.
 
> C <= B - A * stuff;
> D <= A + C;  -- A changes and puts D outside of its range until C is
> updated
 
> In the real world, this is not really an issue since all sorts of
> intermediate states are expected when doing arithmetic.  But VHDL
> doesn't seem to accommodate this well.  

I don't think verilog has this problem, but it might just be
because I would do it with reg [32] and not integer.   I think
you can do something similar to reg [32] in VHDL, and likely
avoid the problem.

(snip)

-- glen

Article: 149980
Subject: Re: Concurrent Logic Timing
From: Jonathan Ross <TheProperNoun@psychophile.com>
Date: Sat, 4 Dec 2010 17:05:54 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 4, 5:32=A0pm, rickman <gnu...@gmail.com> wrote:
> I suppose this is something that you need to expect, but I just have
> never come across this before. =A0I have some concurrent logic equations
> using integers where one input common to two assignments changes and
> because one gets updated before the other, one is set to a value that
> is outside the range of the integer and flags an error in
> simulation.
>
> C <=3D B - A * stuff;
> D <=3D A + C; =A0-- A changes and puts D outside of its range until C is
> updated
>
> In the real world, this is not really an issue since all sorts of
> intermediate states are expected when doing arithmetic. =A0But VHDL
> doesn't seem to accommodate this well. =A0The only way I can think of to
> fix this, without changing the logic, is to do these calculations
> inside a combinatorial process using variables. =A0Then I can control
> the sequence of updates explicitly.
>
> The only other thing I can think is to assign A to A' and use A' in
> place of A in the assignment for D. =A0That may still allow an error,
> but if A'' is used, then there will be two delta delays in D
> assignment path. =A0However, if C grows because A has shrunk, then that
> could cause the same sort of out of bounds error on D.
>
> Is there another way make this work that isn't so cumbersome?
>
> Rick

Try using either the SIGNED or UNSIGNED type instead of integer.

Article: 149981
Subject: Re: Concurrent Logic Timing
From: rickman <gnuarm@gmail.com>
Date: Sat, 4 Dec 2010 19:55:34 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 4, 8:05=A0pm, Jonathan Ross <TheProperN...@psychophile.com>
wrote:
> On Dec 4, 5:32=A0pm, rickman <gnu...@gmail.com> wrote:
>
>
>
> > I suppose this is something that you need to expect, but I just have
> > never come across this before. =A0I have some concurrent logic equation=
s
> > using integers where one input common to two assignments changes and
> > because one gets updated before the other, one is set to a value that
> > is outside the range of the integer and flags an error in
> > simulation.
>
> > C <=3D B - A * stuff;
> > D <=3D A + C; =A0-- A changes and puts D outside of its range until C i=
s
> > updated
>
> > In the real world, this is not really an issue since all sorts of
> > intermediate states are expected when doing arithmetic. =A0But VHDL
> > doesn't seem to accommodate this well. =A0The only way I can think of t=
o
> > fix this, without changing the logic, is to do these calculations
> > inside a combinatorial process using variables. =A0Then I can control
> > the sequence of updates explicitly.
>
> > The only other thing I can think is to assign A to A' and use A' in
> > place of A in the assignment for D. =A0That may still allow an error,
> > but if A'' is used, then there will be two delta delays in D
> > assignment path. =A0However, if C grows because A has shrunk, then that
> > could cause the same sort of out of bounds error on D.
>
> > Is there another way make this work that isn't so cumbersome?
>
> > Rick
>
> Try using either the SIGNED or UNSIGNED type instead of integer.

I see what the two of you are saying.  By using integer it will be
tested for range bounds.  std_logic_vector types don't get that level
of analysis.  The range testing is useful when it is done properly.
By properly, I mean so that it is checking the logic, not your skill
at eliminating glitches in combinatorial logic...

For the short term I put it in a combinatorial process.  The other
thing that would have been pretty easy would be to combine the two
into one assignment.  The first assignment was just an intermediate to
facilitate debugging.

I guess I'm just surprised that I've never been bitten by this
before.

Rick

Article: 149982
Subject: Re: : The Danger of When Programmable Logic Meets the Consumer Market
From: "stephen.craven@gmail.com" <stephen.craven@gmail.com>
Date: Sat, 4 Dec 2010 20:02:16 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 3, 4:35=A0pm, Prevailing over Technology <steve.kn...@prevailing-
technology.com> wrote:
> Okay, perhaps this a little off topic, but here's a video that I and
> others might find funny courtesy of the MachXO2 folks at Lattice.
> Just so you know, yes, it's a spoof of that great American classic--
> the informercial. =A0Think Sham Wow, but for silicon.
>
> http://www.youtube.com/watch?v=3Dh_USk-HNgPA

Is the Smockie lab coat mentioned for real, or is it Vaporwear?

Article: 149983
Subject: Re: FSM single process...BIG question
From: "carlob" <carlo.beccia@n_o_s_p_a_m.n_o_s_p_a_m.libero.it>
Date: Sun, 05 Dec 2010 05:05:12 -0600
Links: << >>  << T >>  << A >>

>I went through the exercise with the example to see how messy it would
>be.
>
>library ieee;
>use ieee.std_logic_1164.all;
>use ieee.numeric_std.all;
>
>entity state_test is
>
>  port (
>    clk     : in std_logic;
>    reset   : in std_logic;
>    txValid : in std_logic;
>    txReady : in std_logic;
>    dataIn  : in std_logic_vector(7 downto 0);
>
>    tx_data_out : out std_logic_vector(7 downto 0)
>    );
>
>end state_test;
>
>architecture behav of state_test is
>  type state_typ is (TXD_IDLE, TXD_ACTIVE, TXD_END);
>
>  signal act_txd_state               : state_typ :=3D TXD_IDLE;
>  signal tx_data_next, tx_data : std_logic_vector(7 downto 0);
>
>begin
>  tx_data_out <=3D tx_data_next;
>
>  tx_data_next <=3D
>    "00000000" when reset =3D
>'1'
>else
>    "01000000" when ((act_txd_state =3D TXD_IDLE) and (txValid =3D '1')
>and (dataIn =3D "00000000"))  else
>    "11000000" when ((act_txd_state =3D TXD_IDLE) and (txValid =3D '1')
>and (dataIn /=3D "00000000")) else
>    dataIn     when ((act_txd_state =3D
>TXD_END))
>else
>    tx_data;
>
>  sync_proc : process (clk, reset) is
>  begin
>    if (reset =3D '1') then
>      act_txd_state <=3D TXD_IDLE;
>      tx_data       <=3D (others =3D> '0');
>    elsif (clk'event and clk =3D '1') then
>      tx_data <=3D tx_data_next;
>
>      case act_txd_state is
>
>        when TXD_IDLE =3D>
>          if (txValid =3D '1') then
>            act_txd_state <=3D TXD_ACTIVE;
>          end if;
>
>
>        when TXD_ACTIVE =3D>
>          if (txReady =3D '1') then
>            act_txd_state <=3D TXD_END;
>          end if;
>
>
>        when TXD_END =3D>
>          if (txValid =3D '0') then
>            act_txd_state <=3D TXD_IDLE;
>          end if;
>      end case;
>
>    end if;
>  end process sync_proc;
>end behav;
>

Yes...indeed that is the only way (or one of few ways) to eliminate the
output FF...
In some way it is "similar" to what I've written with variables but using
concurrent signal assignment....effectively it is not a complete mess...

Anyway...probably I was wrong...I don't need to avoid registered output
(and a lot of you were right)...in fact I'm always assigning the "output"
of a FF...therefore I'm sure that when fsm reach a state the output will
change to the value that is required on that state on the same clock front
and I don't have to wait for another clock front to have that value on
output...am I correct???

I saw it in simulation...looking at the RTL synthesys diagram wasn't clear
for me....I have, further, the advantage of registered output....

Probably I will rewrite everything (or the most part) in 1 process
style...it seems more clear....I'm evaluating...

Thanx
Carlo	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 149984
Subject: Re: : The Danger of When Programmable Logic Meets the Consumer Market -- The Informercial
From: Jonathan Bromley <spam@oxfordbromley.plus.com>
Date: Sun, 05 Dec 2010 14:09:01 +0000
Links: << >>  << T >>  << A >>
On Sat, 4 Dec 2010 20:02:16 -0800 (PST), "stephen.craven@gmail.com"
wrote:

>Is the Smockie lab coat [...] Vaporwear?

:-)

Only if you leave the soldering iron on it for too long.
-- 
Jonathan Bromley

Article: 149985
Subject: Re: FPGA BOARD QUESTION
From: John Adair <g1@enterpoint.co.uk>
Date: Sun, 5 Dec 2010 09:46:40 -0800 (PST)
Links: << >>  << T >>  << A >>
From our stable the Pomaddie3, Drigmorn2 and Drigmorn3 boards are good
ones to get going with VHDL. All three of feature traffic light LEDs
to allow designs based on light sequencies and they can all power from
USB making it easy if you want to play. Details of these and other
products http://www.enterpoint.co.uk/boardproducts.html.

John Adair
Enterpoint Ltd.

On Dec 3, 11:01=A0am, RealInfo <therighti...@gmail.com> wrote:
> Hi all
> I need to buy a FPGA evaluation board to practice my comeback
> to the FPGA design with VHDL.
>
> Can you offer me a board that will do that
> =A0based on your experience ?
>
> Thanks
>
> EC


Article: 149986
Subject: Re: FPGA project structure definition
From: Pontus <pontus.stenstrom@gmail.com>
Date: Sun, 5 Dec 2010 10:36:28 -0800 (PST)
Links: << >>  << T >>  << A >>
Great, thanks for sharing.

I have set up an FPGA project organization which ended up quite
similar to yours.
The build dir is introducing (to me) a new level which seems to be a
good idea,
we used sim, synt, par dirs in paralell to the src, doc etc.
We don't have the products dir, instead products (of specific
revisions) are manually archived on a separate archive server.

Also our constraint files have been lying in the synt ans par dirs,
but I like the Idea of just removing the
entire build dir to do a clean.
However I also kind of like to do "cd synt; make" (or "make -C synt")
to get the synthesis done.
So I need to keep at least the makefile when doing a clean.

Often the project has several "products" built from the same sources,
e.g. a "board_test" bit file for production tests,
and possibly some bit file to develop or debug a specific part or
function of the board. Further down the road you may end up
with having to support different FPGAs (i.e different speed grades/
sizes).
Another aspect is when using the project as a submodule, you may want
to be able to publish several variants (16/32, master/slave, etc.)
All this made us come up with the concept of a "component" of a module
(for the lack of a better word (component is probably the most
overloaded word in HW design)).
In our system a module may have several components, e.g. "board_test",
"ddr_debug", "small_fpga" etc.

During build:
Usually there are many warnings in the log files of quite different
severity.
An approach I have taken is to view the log file as the primary goal
in the makefile (for both sim, synt and par).
Or actually a filtered log file obtained by running a (bash) script
using "grep -v" to remove "known and accepted" warnings.
Nothing should be left after the filter has worked on the file. The
filter also does some simple statistics such as reporting
the number of warnings filtered out etc. The filter is setup with a
specific "component" control file that lists all acceptable warnings.
This control file is also an excellent place to document why specific
warnings are acceptable.
So e.g. the (synt result) .edi file is obtained as a side effect of
wanting a filtered synthesis log file.
The filter can have make fail if wished (we currently don't do that).

So the directories we have at the module level is src/ synt/ sim/ par/
doc/ submodule_1/ and design/
"make -C src" will compile (for simulation) all src code including any
generated "macros" from the fpga vendor
"make -C sim" will run a set of batchmode simulations generating
filtered log files which can be inspected.
"make -C synt my_comp" will synt the component my_comp (or actaully
aim to generate my_comp's filtered log file)
"make -C par my_comp" will {build; map; par; trace} my_comp by [again]
aim for a filtered log file.
"make all" in the module top will do all four steps above.

Finally in design/ we keep all build scripts and makefiles and a file
to setup the environment, i.e. paths to all
tools used. In that way we also check in which tools and their
versions that were used for a given project at a given time.

One thing I have noted is that implementing "make help" in each
directory has made the system much more user friendly.

-- Pontus

Article: 149987
Subject: Re: FSM single process...BIG question
From: "carlob" <carlo.beccia@n_o_s_p_a_m.n_o_s_p_a_m.libero.it>
Date: Sun, 05 Dec 2010 16:20:30 -0600
Links: << >>  << T >>  << A >>
>Anyway...probably I was wrong...I don't need to avoid registered output
>(and a lot of you were right)...in fact I'm always assigning the "output"
>of a FF...therefore I'm sure that when fsm reach a state the output will
>change to the value that is required on that state on the same clock
front
>and I don't have to wait for another clock front to have that value on
>output...
This is not completely true...state change immediately if change condition
is met...output is still at values on previous state...on the next clock
front the output goes to the new state value...this is the effect of the
output FF...I'm sorry a misunderstanding....

..the difference is now clear....I've just simulated the two
situations...(1 process, 2 process-no register)...and checked the
differences....

Anyway...since all input signals "should be sinchronous" to the raise front
of the clock and the produced output MUST be synch I think that the best
way to achieve that is registering output and evaluating input on clock
raise...my previous implementation was wrong because output is allowed to
change asynchronously...I have to correct...and I think that 1 process
style fit better the requirements...

If in some cases I will need to unreg output I will use concurrent
statements outside of the process as pointed out in the discussion...

Thanx to everyone who helped me...
Carlo   
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 149988
Subject: Re: FSM single process...BIG question
From: rickman <gnuarm@gmail.com>
Date: Sun, 5 Dec 2010 14:43:38 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 5, 5:20=A0pm, "carlob"
<carlo.beccia@n_o_s_p_a_m.n_o_s_p_a_m.libero.it> wrote:
> >Anyway...probably I was wrong...I don't need to avoid registered output
> >(and a lot of you were right)...in fact I'm always assigning the "output=
"
> >of a FF...therefore I'm sure that when fsm reach a state the output will
> >change to the value that is required on that state on the same clock
> front
> >and I don't have to wait for another clock front to have that value on
> >output...
>
> This is not completely true...state change immediately if change conditio=
n
> is met...output is still at values on previous state...on the next clock
> front the output goes to the new state value...this is the effect of the
> output FF...I'm sorry a misunderstanding....

No, something is wrong with your understanding.  If your outputs are
defined at the same time as the next staate is defined, you can get
the outputs changing at the time as the state.  It just means the
outputs will use similar logic to the state logic and will depend on
both the current state and the inputs, just as the state does.  This
can all be in one process.

The only limitation of a one process FSM is that the outputs can only
respond to the inputs at a clock boundary.  There are cases where the
output needs to change as soon as the input changes without waiting
for the next clock.


> ..the difference is now clear....I've just simulated the two
> situations...(1 process, 2 process-no register)...and checked the
> differences....

If you are finding your outputs to be changing one clock cycle after
the state changes, then you aren't coding the output to depend on the
input, only the state.


> Anyway...since all input signals "should be sinchronous" to the raise fro=
nt
> of the clock and the produced output MUST be synch I think that the best
> way to achieve that is registering output and evaluating input on clock
> raise...my previous implementation was wrong because output is allowed to
> change asynchronously...I have to correct...and I think that 1 process
> style fit better the requirements...

An output can be synchronous and still be purely combinatorial.  All
logic between registers is combinatorial, it has nothing to do with
how you code your HDL.


> If in some cases I will need to unreg output I will use concurrent
> statements outside of the process as pointed out in the discussion...

But if you need your output registers to change at the same clock edge
as the state, that shouldn't be a problem.  You don't need
combinatorial code to do that.

Rick

Article: 149989
Subject: Re: FPGA project structure definition
From: Alessandro Basili <alessandro.basili@cern.ch>
Date: Mon, 06 Dec 2010 02:18:29 +0100
Links: << >>  << T >>  << A >>
On 12/3/2010 1:32 PM, saar drimer wrote:
> I've written up an (informal) draft proposal for an FPGA project
> structure that could be easily extended as the project grows and is
> version control friendly. I'd be grateful for any type of feedback...
>
>    http://www.saardrimer.com/fpgaproj/
>
> cheers,
> saar.

First of all I'd like to point out that your proposal looks consistent 
and in some aspects very elegant. I like the idea of having a common 
structured approach everyone understands and follows rigorously and 
methodically, in order to promote reuse and modular design.

On the contrary I believe the effort becomes huge when you need to deal 
with FPGA vendors, since every one is pushing their own product and 
through their own Integrated Development Environment they tie down the 
designers to their own structure.

As already posted, I also like the idea of cleaning a build in one go, 
but I think that a constraint file is pretty much different from an hdl 
file and collecting them under /source will make a lot of confusion, 
especially when you are interested in developing rtl while some other 
people are interested in adding constraints for the implementation.
Dividing the dir tree in processes has the big advantage that even 
though you are the only one designer, you make your project flowing, in 
several reiterations, with the processes. Once you are happy with the 
simulation and the rtl you would move into synthesis and so on (with a 
good chance you need to come back to your rtl).

In the end I believe that having a structure, regardless the type, is 
the most important thing, since nothing can be more confusing than 
having no organization. I sometimes stare for minutes at the list of 
directory names my group is creating and believe that no matter what 
structure you want to propose their capability to screw it up is greatly 
above any imagination (I still remember my very first vhdl project soon 
moved from directory /test to directory /final and then /reallyfinal and 
then /reallyfinal2...).

Article: 149990
Subject: Re: Opinions on Lattice ECP3
From: David Brown <david@westcontrol.removethisbit.com>
Date: Mon, 06 Dec 2010 08:59:32 +0100
Links: << >>  << T >>  << A >>
On 03/12/2010 17:23, Gabor wrote:

> I don't know if someone already covered this point, but the free
> tools do not cover the ECP3 devices.  You'll need to buy the full

I don't think anyone else pointed it out, but I've just noticed it 
myself.  It's not particularly expensive, but it's always an 
inconvenience when you have software locked to a particular machine.  It 
makes it harder to split work between an office PC and a home PC.

> license. Also as Raymund pointed out, the DDR memory controller is
> additional money.

Do you have any ideas about the price?  I have in the past heard prices 
for memory controllers and other common-place IPs that were a digit or 
two more than I would expect.  On the other hand, competitors like 
Altera include DDR controllers in their full license tools.

> I've developed a few products with Lattice ECP
> and ECP2 parts.  It's worth taking a good look at the clock routing
> to make sure you don't get in trouble with high-speed I/O logic.
> Specifically there are only a couple of edge clock routes per side of
> the parts and the sources for each route are limited. So it becomes
> hard to make multiple unrelated high-speed interfaces on one side of

Thanks for that tip.

> the chip.  Also the fabric is composed of memory-capable and
> non-memory-capable cells.  But coming from Altera I suppose having
> any distributed memory capability is a plus.  Finally another
> cost-cutting makes the four sides of the device have different
> subsets of the total available I/O standards or features, so again
> read carefully.
>
> I have not used the high-speed SERDES parts from Lattice, so I can't
> comment on that.  If you're trying to do something standard with it
> like DVI/HDMI try to get a reference design to make sure it's
> possible.  Lattice FAE's have been pretty helpful for us.
>

I see they have a kit with an HDMI demonstration.  It's not exactly 
cheap - it's the kind you buy when you have already made the decision on 
the platform, rather than the kind you use to help make the decision. 
But the fact that the boards exist is a good indication of what's possible.

Thanks,

David


Article: 149991
Subject: Re: Opinions on Lattice ECP3
From: David Brown <david@westcontrol.removethisbit.com>
Date: Mon, 06 Dec 2010 09:24:24 +0100
Links: << >>  << T >>  << A >>
On 03/12/2010 18:02, Rob Gaddi wrote:
> On 12/3/2010 12:45 AM, David Brown wrote:
>> Hi,
>>
>> I haven't a lot of experience with FPGA design, but have done a few
>> projects - mostly with Altera Cyclones, some with a Nios II. We are
>> looking at making a new design that should be low cost, but needs a high
>> speed serial interface (for reading in a DVI and/or HDMI signal).
>>
>> The obvious choice then is Lattice ECP3 (but I am very happy to hear
>> alternative suggestions).
>>
>>
>> I've already had a look at quite a bit of the website, so I'll looking
>> mainly for information that is not there - a website will seldom tell
>> you that their software feels slow and awkward, or fast and intuitive.
>> And a website will often tell you things are free or "low cost", but the
>> small print and hidden costs are, well, small and hidden.
>>
>>
>> I haven't used any Lattice tools for nearly ten years, and that was for
>> CPLD design. My guess is that things have changed a little since then.
>>
>> Are there anything major problems or obstacles that should make me
>> reconsider before getting in too deep? I'd like to avoid doing the
>> design and then finding out that Lattice only sells in 10,000
>> quantities, or that the tools are useless without buying many
>> kilodollars of third-party software.
>>
>>
>> For the development software, I can only name a few features of Quartus
>> and ask if Lattice software is similar. I like the integration of
>> Quartus - it feels like a single coordinated tool. Is that also the case
>> with modern Lattice software? The tools I used long ago felt more like a
>> collection of different bits and pieces, such as two separate synthesis
>> engines that couldn't agree on anything.
>>
>> I also like Quartus SOPC builder - we might be putting a micro and a
>> DDR2 memory interface in this design, and SOPC builder is definitely a
>> convenient way to set put this together. Does Lattice have something
>> similar? Obviously it will be geared towards the Micro32 rather than the
>> Nios, but that's fine by me.
>>
>>
>> How are the free tools compared to the paid-for tools? I'm okay with
>> paying for the tools if that's necessary, but it is very nice having
>> free versions that will do a good job. Amongst other things, it makes it
>> more convenient to work from different computers (such as at a home
>> office).
>>
>>
>> Finally, there is the question of ready-made IP. The main parts I'd be
>> interested in here are a DDR2 memory interface, an embedded micro, and
>> possibly a DVI/HDMI receiver. I gather the micro32 is ready to use, free
>> (and open), and has a full gcc toolchain, so that should be a simple
>> choice (and the micro8 is a smaller alternative). It may be that I'll
>> have to make all or part of the DVI/HDMI receiver, though it would be
>> nice to get ready-made if it's not /too/ expensive. But the DDR2
>> interface is definitely something we should get ready-made.
>>
>>
>> Thanks for any hints, pointers or opinions.
>>
>> mvh.,
>>
>> David
>>
>
> No experience with the Lattice parts, and only just switching to A from
> X recently. But, if you're currently happy with the Altera tools, I seem
> to recall the Arria II chips being price competitive with ECP3. Also,
> have you looked at the Cyclone IV GX chips? They've got high speed
> serial too, although I think availability may be an issue.
>

The Arria II are probably price-competitive with the ECP3 when you get 
above a certain size, but the ECP3 series starts lower.  We don't need a 
great deal out of the FPGA other than the video interface, an embedded 
micro (and even that is optional) and fast external memory.  The Cyclone 
IV GX are a definite possibility - unfortunately the currently-available 
EP4CGX15 is too small (though the price is nice), while the EP4CGX110 is 
far too big.  The EP4CGX22 or 30 would be more appropriate, if they existed.

I'm beginning to think that we'll drop the HDMI input.  It would be nice 
to have an integrated solution, but it looks like it will be much more 
cost-effective to have an external HDMI receiver chip and just read in 
the data as a wide data bus.  Then we can use a Cyclone III or Cyclone 
IV with the tools we have used before.

Thanks,

David

Article: 149992
Subject: Re: Concurrent Logic Timing
From: Kolja Sulimma <ksulimma@googlemail.com>
Date: Mon, 6 Dec 2010 02:09:10 -0800 (PST)
Links: << >>  << T >>  << A >>
On 5 Dez., 04:55, rickman <gnu...@gmail.com> wrote:
> On Dec 4, 8:05=A0pm, Jonathan Ross <TheProperN...@psychophile.com>
> wrote:
>
>
>
> > On Dec 4, 5:32=A0pm, rickman <gnu...@gmail.com> wrote:
>
> > > I suppose this is something that you need to expect, but I just have
> > > never come across this before. =A0I have some concurrent logic equati=
ons
> > > using integers where one input common to two assignments changes and
> > > because one gets updated before the other, one is set to a value that
> > > is outside the range of the integer and flags an error in
> > > simulation.
>
> > > C <=3D B - A * stuff;
> > > D <=3D A + C; =A0-- A changes and puts D outside of its range until C=
 is
> > > updated
>
> > > In the real world, this is not really an issue since all sorts of
> > > intermediate states are expected when doing arithmetic. =A0But VHDL
> > > doesn't seem to accommodate this well. =A0The only way I can think of=
 to
> > > fix this, without changing the logic, is to do these calculations
> > > inside a combinatorial process using variables. =A0Then I can control
> > > the sequence of updates explicitly.
>
> > > The only other thing I can think is to assign A to A' and use A' in
> > > place of A in the assignment for D. =A0That may still allow an error,
> > > but if A'' is used, then there will be two delta delays in D
> > > assignment path. =A0However, if C grows because A has shrunk, then th=
at
> > > could cause the same sort of out of bounds error on D.
>
> > > Is there another way make this work that isn't so cumbersome?
>
> > > Rick
>
> > Try using either the SIGNED or UNSIGNED type instead of integer.
>
> I see what the two of you are saying. =A0By using integer it will be
> tested for range bounds. =A0std_logic_vector types don't get that level
> of analysis. =A0The range testing is useful when it is done properly.
> By properly, I mean so that it is checking the logic, not your skill
> at eliminating glitches in combinatorial logic...

Use signed or unsigned from the numeric_std package and perform the
range check yourself
at times when you know the intermediate states have settled:

if rising_edge(clk) then
  assert c >=3D lower_bound and c <=3D upper_bound report "C out of
range";
end if;

I believe that virtually all HDL-Designers should use a lot more
assertions than they do.
(Myself included.)

Kolja


Article: 149993
Subject: Re: FSM single process...BIG question
From: "carlob" <carlo.beccia@n_o_s_p_a_m.n_o_s_p_a_m.libero.it>
Date: Mon, 06 Dec 2010 04:18:20 -0600
Links: << >>  << T >>  << A >>
>On Dec 5, 5:20=A0pm, "carlob"
><carlo.beccia@n_o_s_p_a_m.n_o_s_p_a_m.libero.it> wrote:
>> >Anyway...probably I was wrong...I don't need to avoid registered
output
>> >(and a lot of you were right)...in fact I'm always assigning the
"output=
>"
>> >of a FF...therefore I'm sure that when fsm reach a state the output
will
>> >change to the value that is required on that state on the same clock
>> front
>> >and I don't have to wait for another clock front to have that value on
>> >output...
>>
>> This is not completely true...state change immediately if change
conditio=
>n
>> is met...output is still at values on previous state...on the next
clock
>> front the output goes to the new state value...this is the effect of
the
>> output FF...I'm sorry a misunderstanding....
>
>No, something is wrong with your understanding.  If your outputs are
>defined at the same time as the next staate is defined, you can get
>the outputs changing at the time as the state.  It just means the
>outputs will use similar logic to the state logic and will depend on
>both the current state and the inputs, just as the state does.  This
>can all be in one process.

Hi Rick...yes...it is definitely....I understand your point...I think that
we are expressing the same concept in different ways...it is not easy to
explain without an example.....

>The only limitation of a one process FSM is that the outputs can only
>respond to the inputs at a clock boundary.  There are cases where the
>output needs to change as soon as the input changes without waiting
>for the next clock.
>

Yes...definitely...I agree...that is another important difference....

>An output can be synchronous and still be purely combinatorial.  All
>logic between registers is combinatorial, it has nothing to do with
>how you code your HDL.
>
>
>> If in some cases I will need to unreg output I will use concurrent
>> statements outside of the process as pointed out in the discussion...
>
>But if you need your output registers to change at the same clock edge
>as the state, that shouldn't be a problem.  You don't need
>combinatorial code to do that.
>
>Rick

Yes...I agree again....what I wanted to say is that my input should be
synch with the clock...therefore I think that is a requirement to evaluate
their change only on a clock front...the output will change on a clock
front too...
1 process approach seems to fit better (input are evaluated on clock
raise/fall and, obviously, output will change only on a clock
raise/fall...)...I don't wanted to say that you cannot do with
combinatorial logic...but, in that case, you have to explicitily code FFs
to have that (input and output)...with 1 process it is not needed...FFs are
implicit in the HDL...

Hope to have explained my point...it is diffucult to say in words this kind
of concepts...

Thanx
Carlo


	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 149994
Subject: Re: FSM single process...BIG question
From: "RCIngham" <robert.ingham@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Mon, 06 Dec 2010 04:20:08 -0600
Links: << >>  << T >>  << A >>
>>Anyway...probably I was wrong...I don't need to avoid registered output
>>(and a lot of you were right)...in fact I'm always assigning the
"output"
>>of a FF...therefore I'm sure that when fsm reach a state the output will
>>change to the value that is required on that state on the same clock
>front
>>and I don't have to wait for another clock front to have that value on
>>output...
>This is not completely true...state change immediately if change
condition
>is met...output is still at values on previous state...on the next clock
>front the output goes to the new state value...this is the effect of the
>output FF...I'm sorry a misunderstanding....
>
>..the difference is now clear....I've just simulated the two
>situations...(1 process, 2 process-no register)...and checked the
>differences....
>
>Anyway...since all input signals "should be sinchronous" to the raise
front
>of the clock and the produced output MUST be synch I think that the best
>way to achieve that is registering output and evaluating input on clock
>raise...my previous implementation was wrong because output is allowed to
>change asynchronously...I have to correct...and I think that 1 process
>style fit better the requirements...
>
>If in some cases I will need to unreg output I will use concurrent
>statements outside of the process as pointed out in the discussion...
>
>Thanx to everyone who helped me...
>Carlo   
>

Something that no-one seems to have brought up (sorry if I missed it) is
whether you are trying to implement a Mealy FSM or a Moore FSM. What you
are doing will infer a Mealy FSM, but I suspect that you don't know why you
are using that version. Reading up on the difference should be helpful -
there is a lot of stuff available on the Interwebs that any decent search
engine will find.

For high-speed stuff, I usually go for a Moore FSM, but with registered
outputs via a slightly subtle variation.
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 149995
Subject: Re: FSM single process...BIG question
From: "carlob" <carlo.beccia@n_o_s_p_a_m.n_o_s_p_a_m.libero.it>
Date: Mon, 06 Dec 2010 05:02:04 -0600
Links: << >>  << T >>  << A >>

>Something that no-one seems to have brought up (sorry if I missed it) is
>whether you are trying to implement a Mealy FSM or a Moore FSM. What you
>are doing will infer a Mealy FSM, but I suspect that you don't know why
you
>are using that version. Reading up on the difference should be helpful -
>there is a lot of stuff available on the Interwebs that any decent search
>engine will find.
>
>For high-speed stuff, I usually go for a Moore FSM, but with registered
>outputs via a slightly subtle variation.
>	   
>					
>---------------------------------------		
>Posted through http://www.FPGARelated.com
>

Hi,
Yes...it was a Mealy FSM...the output depends on state and
input...otherwise you can add more states and move to Moore...but...when
you register the output are you already going toward Moore or not??? I
think that are similar...

It could be interesting to have more info on the the high-speed stuff...

Thanx
Carlo	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 149996
Subject: Lattice XO2 video
From: Mike Harrison <mike@whitewing.co.uk>
Date: Mon, 06 Dec 2010 11:13:52 +0000
Links: << >>  << T >>  << A >>
http://www.youtube.com/watch?v=h_USk-HNgPA&feature=player_detailpage

Come on X and A - spice up your promo  videos!

Article: 149997
Subject: Re: : The Danger of When Programmable Logic Meets the Consumer Market -- The Informercial
From: Anders.Montonen@kapsi.spam.stop.fi.invalid
Date: Mon, 6 Dec 2010 13:15:12 +0000 (UTC)
Links: << >>  << T >>  << A >>
stephen.craven@gmail.com <stephen.craven@gmail.com> wrote:
> Is the Smockie lab coat mentioned for real, or is it Vaporwear?

Badum-tish. The product page mentioned in the video exists, but is a joke
(<http://www.latticesemi.com/products/cpld/machxo2/smockie.cfm>), but if
they don't have them to give out at trade shows they're fools.

-a

Article: 149998
Subject: Re: Opinions on Lattice ECP3
From: rickman <gnuarm@gmail.com>
Date: Mon, 6 Dec 2010 05:48:20 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 6, 2:59=A0am, David Brown <da...@westcontrol.removethisbit.com>
wrote:
> On 03/12/2010 17:23, Gabor wrote:
>
> > I don't know if someone already covered this point, but the free
> > tools do not cover the ECP3 devices. =A0You'll need to buy the full
>
> I don't think anyone else pointed it out, but I've just noticed it
> myself. =A0It's not particularly expensive, but it's always an
> inconvenience when you have software locked to a particular machine. =A0I=
t
> makes it harder to split work between an office PC and a home PC.

I can't say about other tool vendors, but Lattice has always been very
good about licensing multiple machines.  When I originally bought the
tools they allowed me to license the two machine I used.  Then when I
replaced one they licensed the new machine as well.


> > license. Also as Raymund pointed out, the DDR memory controller is
> > additional money.
>
> Do you have any ideas about the price? =A0I have in the past heard prices
> for memory controllers and other common-place IPs that were a digit or
> two more than I would expect. =A0On the other hand, competitors like
> Altera include DDR controllers in their full license tools.

It all depends on the model.  One advantage of the Lattice IP is the
open source license on the Lattice CPUs.  If you invest the time in
creating code for the Lattice CPU, you won't have to port that to a
new CPU if you want to target a different brand of FPGA or move to an
ASIC.

Rick

Article: 149999
Subject: Re: Opinions on Lattice ECP3
From: rickman <gnuarm@gmail.com>
Date: Mon, 6 Dec 2010 05:54:07 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 6, 3:24=A0am, David Brown <da...@westcontrol.removethisbit.com>
wrote:
> On 03/12/2010 18:02, Rob Gaddi wrote:
>
>
>
> > On 12/3/2010 12:45 AM, David Brown wrote:
> >> Hi,
>
> >> I haven't a lot of experience with FPGA design, but have done a few
> >> projects - mostly with Altera Cyclones, some with a Nios II. We are
> >> looking at making a new design that should be low cost, but needs a hi=
gh
> >> speed serial interface (for reading in a DVI and/or HDMI signal).
>
> >> The obvious choice then is Lattice ECP3 (but I am very happy to hear
> >> alternative suggestions).
>
> >> I've already had a look at quite a bit of the website, so I'll looking
> >> mainly for information that is not there - a website will seldom tell
> >> you that their software feels slow and awkward, or fast and intuitive.
> >> And a website will often tell you things are free or "low cost", but t=
he
> >> small print and hidden costs are, well, small and hidden.
>
> >> I haven't used any Lattice tools for nearly ten years, and that was fo=
r
> >> CPLD design. My guess is that things have changed a little since then.
>
> >> Are there anything major problems or obstacles that should make me
> >> reconsider before getting in too deep? I'd like to avoid doing the
> >> design and then finding out that Lattice only sells in 10,000
> >> quantities, or that the tools are useless without buying many
> >> kilodollars of third-party software.
>
> >> For the development software, I can only name a few features of Quartu=
s
> >> and ask if Lattice software is similar. I like the integration of
> >> Quartus - it feels like a single coordinated tool. Is that also the ca=
se
> >> with modern Lattice software? The tools I used long ago felt more like=
 a
> >> collection of different bits and pieces, such as two separate synthesi=
s
> >> engines that couldn't agree on anything.
>
> >> I also like Quartus SOPC builder - we might be putting a micro and a
> >> DDR2 memory interface in this design, and SOPC builder is definitely a
> >> convenient way to set put this together. Does Lattice have something
> >> similar? Obviously it will be geared towards the Micro32 rather than t=
he
> >> Nios, but that's fine by me.
>
> >> How are the free tools compared to the paid-for tools? I'm okay with
> >> paying for the tools if that's necessary, but it is very nice having
> >> free versions that will do a good job. Amongst other things, it makes =
it
> >> more convenient to work from different computers (such as at a home
> >> office).
>
> >> Finally, there is the question of ready-made IP. The main parts I'd be
> >> interested in here are a DDR2 memory interface, an embedded micro, and
> >> possibly a DVI/HDMI receiver. I gather the micro32 is ready to use, fr=
ee
> >> (and open), and has a full gcc toolchain, so that should be a simple
> >> choice (and the micro8 is a smaller alternative). It may be that I'll
> >> have to make all or part of the DVI/HDMI receiver, though it would be
> >> nice to get ready-made if it's not /too/ expensive. But the DDR2
> >> interface is definitely something we should get ready-made.
>
> >> Thanks for any hints, pointers or opinions.
>
> >> mvh.,
>
> >> David
>
> > No experience with the Lattice parts, and only just switching to A from
> > X recently. But, if you're currently happy with the Altera tools, I see=
m
> > to recall the Arria II chips being price competitive with ECP3. Also,
> > have you looked at the Cyclone IV GX chips? They've got high speed
> > serial too, although I think availability may be an issue.
>
> The Arria II are probably price-competitive with the ECP3 when you get
> above a certain size, but the ECP3 series starts lower. =A0We don't need =
a
> great deal out of the FPGA other than the video interface, an embedded
> micro (and even that is optional) and fast external memory. =A0The Cyclon=
e
> IV GX are a definite possibility - unfortunately the currently-available
> EP4CGX15 is too small (though the price is nice), while the EP4CGX110 is
> far too big. =A0The EP4CGX22 or 30 would be more appropriate, if they exi=
sted.
>
> I'm beginning to think that we'll drop the HDMI input. =A0It would be nic=
e
> to have an integrated solution, but it looks like it will be much more
> cost-effective to have an external HDMI receiver chip and just read in
> the data as a wide data bus. =A0Then we can use a Cyclone III or Cyclone
> IV with the tools we have used before.

That's an interesting trade off.  Lattice came out with SERDES on
their low cost chips as a marketing move because neither X or A
offered SERDES on their low cost lines.  Your preference may be to
stick with the higher cost approach of using an additional chip rather
than going with a new company and new tools. I can't say I blame you
really.  I don't have that concern with any of X, A or L.  I guess
I've used all three enough to be confident that I can make my design
work regardless.

Rick



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