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
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. -- GaborArticle: 149976
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 KellettArticle: 149977
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: 149978I 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? RickArticle: 149979
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) -- glenArticle: 149980
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
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. RickArticle: 149982
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
>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.comArticle: 149984
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 BromleyArticle: 149985
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 > > ECArticle: 149986
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>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.comArticle: 149988
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. RickArticle: 149989
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
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, DavidArticle: 149991
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, DavidArticle: 149992
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.) KoljaArticle: 149993
>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.comArticle: 149994
>>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.comArticle: 149995
>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.comArticle: 149996
http://www.youtube.com/watch?v=h_USk-HNgPA&feature=player_detailpage Come on X and A - spice up your promo videos!Article: 149997
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. -aArticle: 149998
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. RickArticle: 149999
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:
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