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 03/12/2010 11:45, Michael Kellett wrote: > "David Brown"<david@westcontrol.removethisbit.com> wrote in message > news:uMOdncQg25wsMGXRnZ2dnUVZ8r6dnZ2d@lyse.net... >> 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 >> >> >> >> > > I can't answer all of your questions because my work with Lattice parts has > not used the Mico32 or a DDR2 interface. > > In general I have found Lattice much easier to get on with than X (no > experience with A). I use the paid for tool with my own license for Aldec > HDL. I only use small quantitites of parts and buy them through distributors > with no trouble. > I have almost no experience with X tools either, but from what I have heard in this group (amongst other sources), being easier to use than X tools is not hard... The distributors we use here in Norway are all very good, so if /they/ have no trouble getting Lattice chips, then /we/ will have no trouble. > Lattice have always given me a license file for any machine I wanted without > the slightest quibble. > > I haven't had any issues with software bugs in the Lattice tools (can't > believe I just wrote that but it's true !). > This is all excellent news for me. Thanks. > I think your projects sound a bit bigger than mine so your experience may be > different. > All projects are different, so your comments are as valuable as any others (especially as it's the first reply!). Thanks, DavidArticle: 149951
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.Article: 149952
> >> Yes code is very simple...I've already coded a version with 2 process and >> 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 choose >> 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 = active then > sig_a <= '0'; >elsif rising_edge(clk) > sig_a <= input_a; >end if; >end process; > >comb_out <= (sig_a xor input_a) when fsm_state=idle else '0'; > > Hi, that's only because that is a simple fsm inside a project...and 1 clock latency on that signal doesn't fit with other modules.... Yes...I agree with you...I tend to use registers when possible...using 2 process style (till now) you have to take care of registering output therefore is up to you to decide... Thanx Carlo --------------------------------------- Posted through http://www.FPGARelated.comArticle: 149953
>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'; > >I agree with Thomas; in register-rich environment, use those regs. >Great for portability, modularity, and performance. > >I find the choices of fsm coding styles fascinating. Myself, I use the >dual method (make sure all inputs in sensitivity list of comb. >process!), but I always keep my "control" signals separate from either >of these processes, and try to register those as well. (e.g. in >clocked process, if ((pstate =3D s3) OR (pstate =3D s4) mux_select <=3D >DATA_A; else mux_select <=3D DATA_B;) > >But what's the desire to combine all processes into one? It certainly >is efficient coding; only one clk/reset structure. But I find that >method somewhat confusing to read and understand. In fact, when I have >to understand someone else's consolidated code, I'll rewrite it >stripping out everything but the fsm states. I'd rather read my FSM >flow in one process and my control variables somewhere else, but I >realize some designers feel the opposite way... >John > Hi, I would like to go deep in both methods...I already manage 2 process....now I would like to improve the 1 process knowledge to better fit my style to every situation... My conclusion is...when your output is regstered (probably very good choise) better to use 1 process style...when some/all outputs are unregistered better dive in 2 process style...that give more flexibility even if is more prone to errors (sensitivity list, inferred latch etc..)... Do you agree??? Thanx Carlo --------------------------------------- Posted through http://www.FPGARelated.comArticle: 149954
Concerning some questions i may give you useful experiences. The ISPlever tool seems quite reliable and workable, although far not as nicely integrated, "consistent" and polished like Quartus. But a experienced user doesn't need Quartus because of that. Thank God they kept the ISPlever simple and rather efficient. I dont use the new Diamond tool and can't tell much about it but they say only the GUI has changed. The newly supplied third party tool Synpllify replacing Mentor Precision gives me more trouble. Hints: Inefficient carry chain synthesis and system-verilog support / crashes. For a DDR2 memory interface IP you'll have to pay a little, but you can evaluate it. Study their website. Concerning DVI/HDMI receiver they may also have something i saw at a tradehow.Article: 149955
>On 03/12/2010 11:45, Michael Kellett wrote: >> "David Brown"<david@westcontrol.removethisbit.com> wrote in message >> news:uMOdncQg25wsMGXRnZ2dnUVZ8r6dnZ2d@lyse.net... >>> 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 >>> >>> >>> >>> Hello, As far as my short experience with ECP3 is concerned, I noted the following: - their PLL is much less configurable than the ones from Altera. You find yourself very often with unsynthesisable frequencies, and I remember it being unable to make an output frequency less than 2 MHz whatever the input frequency. - their Reveal software (equivalent Signal Tap or Chipscope) is very slow as soon as you put too many signals or too much memory. Let's say that you put 15 signals with 1024k, you'll have to wait 15 or 20 seconds for your trigger to work and display the result. - The tools have a Xilinx "feel". I found it difficult sometimes to trace the origin of a warning because not enough information is given. The Chip and constraints Editor is not very easy to lauch (because if I am correct, it is not really integrated to ISPLever) and to use. But maybe all these cosmetic troubles will disappear with Diamond. Apart from that, the general feeling is good. I had no problem using some of their IP, no known bug or extra difficulties due to the technology. The tools may look less professionnal than Altera or Xilinx, but in the end, they have no bugs and it does not cost you a lot more in time to do the job. And the FPGA works perfectly. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 149956
On 03/12/2010 15:29, krakatoa wrote: >> On 03/12/2010 11:45, Michael Kellett wrote: >>> "David Brown"<david@westcontrol.removethisbit.com> wrote in message >>> news:uMOdncQg25wsMGXRnZ2dnUVZ8r6dnZ2d@lyse.net... >>>> 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 >>>> >>>> >>>> >>>> > Hello, > > As far as my short experience with ECP3 is concerned, I noted the > following: > > - their PLL is much less configurable than the ones from Altera. You find > yourself very often with unsynthesisable frequencies, and I remember it > being unable to make an output frequency less than 2 MHz whatever the input > frequency. > I hope the figure of 2 MHz was a typo. But that's useful information - I will need to be careful of which frequencies I need. > - their Reveal software (equivalent Signal Tap or Chipscope) is very slow > as soon as you put too many signals or too much memory. Let's say that you > put 15 signals with 1024k, you'll have to wait 15 or 20 seconds for your > trigger to work and display the result. > OK. > - The tools have a Xilinx "feel". I found it difficult sometimes to trace > the origin of a warning because not enough information is given. The Chip > and constraints Editor is not very easy to lauch (because if I am correct, > it is not really integrated to ISPLever) and to use. But maybe all these > cosmetic troubles will disappear with Diamond. > OK - it looks like "Diamond" improves on this, but I haven't tried it yet. > Apart from that, the general feeling is good. I had no problem using some > of their IP, no known bug or extra difficulties due to the technology. The > tools may look less professionnal than Altera or Xilinx, but in the end, > they have no bugs and it does not cost you a lot more in time to do the > job. And the FPGA works perfectly. > Nice to know. Thanks, DavidArticle: 149957
> >I hope the figure of 2 MHz was a typo. But that's useful information - >I will need to be careful of which frequencies I need. > No, not a typo. But I did not need a frequency less than 2 MHz, so I did not put much effort in understanding the problem. I hope there is an explanation for this, like improper use of the GUI or something. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 149958
Dear all, I'm trying to set up a development environment to work on an open IP Core that I would like to build against several vendors products. I'm aware of the GHDL utility (also suggested on opencores.org) to simulate the vhdl, but I would like to explore the "makefile script" approach for synthesis and place&route, in order to address vendor specific issues with constraints files, keeping the vhdl source code as much as possible implementation independent. Another reason for this motivation is that I tend to dislike vendors IDE (they are all different and every time I need to deal with different directory structure, GUI and so on). I'd like to know whether there are "best practices" on makefiles for FPGA implementation or if it is possible to have some examples in order to setup a development environment which is consistent throughout all my projects and does not depend on vendor's IDE. Thanks a lot for any suggestions. Best regards, Al -- Alessandro Basili CERN, PH/UGC Electronic EngineerArticle: 149959
On 03/12/2010 16:31, krakatoa wrote: >> >> I hope the figure of 2 MHz was a typo. But that's useful information - >> I will need to be careful of which frequencies I need. >> > > No, not a typo. But I did not need a frequency less than 2 MHz, so I did > not put much effort in understanding the problem. I hope there is an > explanation for this, like improper use of the GUI or something. > Ah, sorry - it was a mis-read rather than a typo. I thought you were saying it could not generate frequencies /greater/ than 2 MHz, which would be a different matter. For frequencies lower than 2 MHz it is usually sufficient to simply divide a faster clock in logic, unless you need to lock to an existing slower frequency.Article: 149960
On Dec 3, 9:55=A0am, David Brown <da...@westcontrol.removethisbit.com> wrote: > On 03/12/2010 15:29, krakatoa wrote: > > > > >> On 03/12/2010 11:45, Michael Kellett wrote: > >>> "David Brown"<da...@westcontrol.removethisbit.com> =A0 wrote in messa= ge > >>>news:uMOdncQg25wsMGXRnZ2dnUVZ8r6dnZ2d@lyse.net... > >>>> 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. =A0We a= re > >>>> 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 looki= ng > >>>> mainly for information that is not there - a website will seldom tel= l > > you > >>>> that their software feels slow and awkward, or fast and intuitive. A= nd > > 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. =A0My 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? =A0I'd like to avoid doing th= e > > design > >>>> and then finding out that Lattice only sells in 10,000 quantities, o= r > > 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. =A0I like the integration of > >>>> Quartus - it feels like a single coordinated tool. =A0Is that also t= he > > case > >>>> with modern Lattice software? =A0The 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. =A0Does Lattice have someth= ing > >>>> similar? =A0Obviously it will be geared towards the Micro32 rather t= han > > the > >>>> Nios, but that's fine by me. > > >>>> How are the free tools compared to the paid-for tools? =A0I'm okay w= ith > >>>> paying for the tools if that's necessary, but it is very nice having > > free > >>>> versions that will do a good job. =A0Amongst 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. =A0The main parts I= 'd > > be > >>>> interested in here are a DDR2 memory interface, an embedded micro, a= nd > >>>> possibly a DVI/HDMI receiver. =A0I gather the micro32 is ready to us= e, > > free > >>>> (and open), and has a full gcc toolchain, so that should be a simple > >>>> choice (and the micro8 is a smaller alternative). =A0It may be that = I'll > >>>> have to make all or part of the DVI/HDMI receiver, though it would b= e > > nice > >>>> to get ready-made if it's not /too/ expensive. =A0But the DDR2 inter= face > > is > >>>> definitely something we should get ready-made. > > >>>> Thanks for any hints, pointers or opinions. > > >>>> mvh., > > >>>> David > > > Hello, > > > As far as my short experience with ECP3 is concerned, I noted the > > following: > > > - their PLL is much less configurable than the ones from Altera. You fi= nd > > yourself very often with unsynthesisable frequencies, and I remember it > > being unable to make an output frequency less than 2 MHz whatever the i= nput > > frequency. > > I hope the figure of 2 MHz was a typo. =A0But that's useful information - > I will need to be careful of which frequencies I need. > > > - their Reveal software (equivalent Signal Tap or Chipscope) is very sl= ow > > as soon as you put too many signals or too much memory. Let's say that = you > > put 15 signals with 1024k, you'll have to wait 15 or 20 seconds for you= r > > trigger to work and display the result. > > OK. > > > - The tools have a Xilinx "feel". I found it difficult sometimes to tra= ce > > the origin of a warning because not enough information is given. The Ch= ip > > and constraints Editor is not very easy to lauch (because if I am corre= ct, > > it is not really integrated to ISPLever) and to use. But maybe all thes= e > > cosmetic troubles will disappear with Diamond. > > OK - it looks like "Diamond" improves on this, but I haven't tried it yet= . > > > Apart from that, the general feeling is good. I had no problem using so= me > > of their IP, no known bug or extra difficulties due to the technology. = The > > tools may look less professionnal than Altera or Xilinx, but in the end= , > > they have no bugs and it does not cost you a lot more in time to do the > > job. And the FPGA works perfectly. > > Nice to know. > > Thanks, > > David 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 license. Also as Raymund pointed out, the DDR memory controller is additional money. 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 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. Regards, GaborArticle: 149961
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. -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 149962
Textbooks are seldom about state of the art in anything. Just because they seem to be in unanimous agreement about one coding method does not mean that the state of the art agrees. Two-process FSMs require twice the declarations, require complex sensitivity lists, require additional code to avoid latches, prohibit using variables to keep local data local, thwart simulation optimizations that take advantage of common sensitivity lists, and a host of other problems. There are two different practical issues at play here. One is whether an output is a combinatorial function of just the state, and one is whether the output is a also a combinatorial function of some combinatorial inputs. The former can be mitigated by assigning registered outputs "early" (i.e. when the FSM transitions to the state, not just when the FSM is already in the state), or by assigning outputs from the state variable after the clocked if statement ends. You appear to want the output to be the latter: a combinatorial function of the registered state and of the unregistered inputs. While you can combine both into one process (with the combinatorial input in the sensitivity list) as Mike has suggested, that is asking for trouble, and if you don't correct the sensitivity list, then the simulation and synthesis results will differ slightly, depending on how/when the output is read by other processes/hardware. It is also potentially prone to creating latches, to which a simple clocked process is immune. You really should create this output in a separate process (or concurrent assignment), but there is no need to separate the FSM into two processes. The best way to avoid latches is to avoid combinatorial processes. If you cannot avoid a combinatorial process, keep it as simple as possible (doing only what has to be done combinatorially) and use up front default assignments. I would suggest you look at your design requirements, and decide what must be combinatorial, and what can tolerate a clock delay. Do you need to avoid a clock delay between tx_valid and tx_data? Do you need to avoid a clock delay between data_in and tx_data? Do you need to avoid a clock delay between tx_ready and tx_data? Make sure you really need to avoid that clock delay. "It would be better if..." does not count. A working design that is simple to write, understand and maintain is much better than a design that is none of those but happens to be a clock cycle faster. Find a way to accomplish combinatorially only what needs to be combinatorial. It appears that tx_data is merely a function of tx_valid, tx_ready, and data_in. What exactly do you need an FSM for? You could use an FSM for error handling (what happens if tx_valid goes high, then low, and tx_ready never fired?). But you don't appear to be using it for that (maybe just to simplify the example?). AndyArticle: 149963
On Dec 2, 5:46 pm, Andy <jonesa...@comcast.net> wrote: > On Dec 2, 2:16 pm, rickman <gnu...@gmail.com> wrote: > > > > > On Dec 2, 9:43 am, "carlob" <carlo.beccia@n_o_s_p_a_m.libero.it> > > wrote: > > > > Hi all, > > > I've a problem to efficiently unregister output from FSM written in a > > > single process style... > > > > in FSM synch process (don't pay attention to syntax..): > > > > case IDLE: > > > if (pippo = '1') then > > > next_state <= START; > > > if (pluto = '1') then > > > outp <= '0'; > > > else > > > outp <= '1'; > > > end if; > > > end if; > > > > outp is registered...if I want to avoid that register I should (in another > > > process) duplicate a lot of logic: > > > > if (state = IDLE) then > > > if (pippo = '1' and pluto = '1') then > > > outp <= '0' > > > elsif (pippo = '1' and pluto = '0') then > > > outp <= '1'; > > > else outp <= 'Z' -- for example > > > end if; > > > end if; > > > > Is it possible to unregister output without duplicating that logic (It > > > seems to me very poor coding...)... > > > > I've read something about using variables...but I don't understand exactly > > > how...please show me an example... > > > You might find it easier to separate the state machine from the state > > register. Then you define all your state transitions and outputs in a > > single process just as you have above, but not a clocked process. > > Instead you need two signals, CurState and NxtState. The > > combinatorial process updates NxtState in terms of CurState with > > CurState and all the other input signals in the sensitivity list, just > > as you have it written now with the outputs registered. The clocked > > process just defines the CurState register in terms of the NxtState > > signal. The clocked process is idiot simple and so does not duplicate > > the code that you are worried about. > > > StateLogicPrc: process (CurState, pippo, pluto,...) begin > > -- if (rising_edge(clk)) then -- remove this sequential stuff from > > the process > > -- so you are just left with the logic... > > case CurState is > > when IDLE: > > if (pippo = '1') then > > next_state <= START; > > if (pluto = '1') then > > outp <= '0'; > > else > > outp <= '1'; > > end if; > > end if; > > ... > > end process StateLogicPrc; > > > StateRegPrc: process (rst, clk) begin > > if (rst = '1') then > > CurState <= StartingState; > > elsif (rising_edge(clk)) then > > CurState <= next_state; > > end if; > > end process StateRegPrc; > > > This style was taught in many text books some 10 years ago because > > some felt the tools did a better job with the two processes > > separated. Now the tools are pretty good no matter what and I think > > this is only used when the output signals are not to be registered as > > in your case. > > > Rick- Hide quoted text - > > > - Show quoted text - > > Rick, > > Your example illustrates exactly why combinatorial processes should be > avoided if possible. You have created a latch (or two)... > > I've read your posts long enough to know that you are an experienced, > talented designer, and in any real design, you would have taken care > of it. But not everyone knows that they need to take care of it, or > knows how. > > The best way to avoid a latch is to avoid a combinatorial process. > The 2nd best way is to include in every combinatorial process, a > default assignment for every output, right up front, before any > conditional logic. This is much easier and more fool-proof than simply > adding an else for every if. > > Andy I wasn't going to provide any code to the OP mainly because I didn't have time to worry with it. But I saw that a verbal explanation wasn't very good and I thought I could get away with a quick edit of his code. Obviously I made a mistake, but that doesn't make combinatorial processes bad. You can also create latches in concurrent statements too. Should you avoid using them as well? I remember when I was just learning VHDL there were things about using integers and variables that I just didn't get. I posted that someone should avoid using them. I was chided for that and I have remembered it since. Just because you don't know how to use a feature effectively doesn't mean no one else should. RickArticle: 149964
On Dec 3, 7:58=A0am, "carlob" <carlo.beccia@n_o_s_p_a_m.n_o_s_p_a_m.libero.it> wrote: > >On Dec 3, 4:05=3DA0am, Thomas Stanka <usenet_nospam_va...@stanka-web.de> > >wrote: > >> > Yes code is very simple...I've already coded a version with 2 proces= s > a=3D > >nd > >> > unregistered output...but, to better > >> > understand, I would like to discover if it is possible in one > process..=3D > >. > > >> > In general..better 1 process and registered outout or 2 process and > cho=3D > >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 =3D3D active then > >> =3DA0 sig_a <=3D3D '0'; > >> elsif rising_edge(clk) > >> =3DA0sig_a <=3D3D input_a; > >> end if; > >> end process; > > >> comb_out <=3D3D (sig_a xor input_a) when fsm_state=3D3Didle else '0'; > > >I agree with Thomas; in register-rich environment, use those regs. > >Great for portability, modularity, and performance. > > >I find the choices of fsm coding styles fascinating. Myself, I use the > >dual method (make sure all inputs in sensitivity list of comb. > >process!), but I always keep my "control" signals separate from either > >of these processes, and try to register those as well. (e.g. in > >clocked process, if ((pstate =3D3D s3) OR (pstate =3D3D s4) mux_select <= =3D3D > >DATA_A; else mux_select <=3D3D DATA_B;) > > >But what's the desire to combine all processes into one? It certainly > >is efficient coding; only one clk/reset structure. But I find that > >method somewhat confusing to read and understand. In fact, when I have > >to understand someone else's consolidated code, I'll rewrite it > >stripping out everything but the fsm states. I'd rather read my FSM > >flow in one process and my control variables somewhere else, but I > >realize some designers feel the opposite way... > >John > > Hi, > I would like to go deep in both methods...I already manage 2 process....n= ow > I would like to improve the 1 process knowledge to better fit my style to > every situation... > > My conclusion is...when your output is regstered (probably very good > choise) better to use 1 process style...when some/all outputs are > unregistered better dive in 2 process style...that give more flexibility > even if is more prone to errors (sensitivity list, inferred latch > etc..)... > > Do you agree??? I agree that I evaluate every case on its own merits. The other thing you could do is to use one process for the state machine and then use concurrent statements for the outputs. I don't use combinatorial processes very often. There are also times when I use concurrent statements for intermediate logic in the state machine. It all depends on what is more clear and that would be up to you to decide. RickArticle: 149965
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. Think Sham Wow, but for silicon. http://www.youtube.com/watch?v=h_USk-HNgPAArticle: 149966
Hi Andy, as you can understand I'm not an expert..... >The former can be mitigated by assigning registered outputs >"early" (i.e. when the FSM transitions to the state, not just when the >FSM is already in the state), or by assigning outputs from the state >variable after the clocked if statement ends. > >pYou appear to want the output to be the latter: a combinatorial >function of the registered state and of the unregistered inputs. > Could you elaborate better on this with an example on my FSM??? >Find a way to accomplish combinatorially only what needs to be >combinatorial. It appears that tx_data is merely a function of >tx_valid, tx_ready, and data_in. What exactly do you need an FSM for? >You could use an FSM for error handling (what happens if tx_valid goes >high, then low, and tx_ready never fired?). But you don't appear to be >using it for that (maybe just to simplify the example?). > >Andy Uhmm...I've written a fsm manly to describe the interface...the output becomes "01000000"/"11000000" when tx_valid goes high depending on data input...then stay on that value till tx_ready becomes high....at that point (on the next clock cycle) tx_data will be equal to datain till tx_valid goes to '0'...yes..I miss probably some error handling...the code is not completely written... Every signal on output should change when clock raise...and every signal in input should change/be checked according to the same clock front....input/output interfaces are synchronous to the clock... How do you describe all this combinatorially??? More simple ways are welcome....if you/somebody wanna help me... :-)) Thanx Carlo --------------------------------------- Posted through http://www.FPGARelated.comArticle: 149967
On Fri, 3 Dec 2010 13:35:39 -0800 (PST), Prevailing over Technology <steve.knapp@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. Think Sham Wow, but for silicon. > >http://www.youtube.com/watch?v=h_USk-HNgPA Pure delight. Thanks! -- Jonathan BromleyArticle: 149968
Andy I've tried one of your suggestion...tell me if I'm wrong (this is a quick written code...probably there are mistakes...pay attention to principle..)... if (reset='1') then act_txd_state := TXD_IDLE; v_delay := '0'; elsif (clk'event and clk ='1') then v_delay := '0'; case act_txd_state is when TXD_IDLE => if (txValid = '1') then act_txd_state := TXD_ACTIVE; end if; when TXD_ACTIVE => if (txReady = '1') then v_delay := '1'; act_txd_state := TXD_END; end if; when TXD_END => if (txValid = '0') then act_txd_state := TXD_IDLE; end if; end case; end if; if (act_txd_state = TXD_ACTIVE) OR (v_delay = '1')then if (dataIn = "00000000") then tx_data <= "01000000"; else tx_data <= "11000000"; end if; elsif (act_txd_state = TXD_END) then tx_data <= dataIn; else tx_data <= "00000000"; end if; This "should" be equivalent (not tested yet)...I've used v_delay FF to delay 1 clock the output change between ACTIVE and END...I've no more registered output...but I've been forced to add dataIn in the sensitivity list (to avoid latches)... That is change you were talking about?? Thanx Carlo --------------------------------------- Posted through http://www.FPGARelated.comArticle: 149969
On Dec 3, 6: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 You really haven't said much. The board you need is greatly dependent on your skill level, your planned projects, the things you want to interface with, etc. It could span anywhere from a tiny Spartan 3 board to a monster Virtex 6 board with PCIe, and a software radio front end. If you are just getting started, there are a bunch of $100- $500 boards listed on the Xilinx and Altera websites. ChrisArticle: 149970
On Dec 2, 9:05=A0am, "andreiseb" <andrei.jacota@n_o_s_p_a_m.gmail.com> wrote: > HI, > > I have a design in which I used the FPGA to access an outside the FPGA IC > through SPI interface. > On the FPGA I have a SPI master controller. The SPI controller has the SP= I > interface signals on one side (that accesses the IC's registers) and a > address and data bus (sometimes Wishbone) on the other side. Now I want t= o > put the information read by the SPI controller inside a RAM. The normal > approach, for me, would be to use a microprocessor that connects to the S= PI > controller, on one side, and to the RAM on the other side. The > microprocessor would read the SPI controller registers and write them in > the RAM. Is there a more simpler approach in which the microprocessor is > not needed? Maybe a controller that does the job? > > Thanks! > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com You could just write a simple FSM to do it all...Article: 149971
On 3 Dez., 22:35, Prevailing over Technology <steve.kn...@prevailing- technology.com> wrote: > http://www.youtube.com/watch?v=h_USk-HNgPA Semiconductor marketing should pick up comedy. I am bored by marketing sending me highly expectable messages like "Our Product is best!" in ever new words. Someone with humour can easily steal the show from the dead serious marketing robot.Article: 149972
On Dec 3, 12:42=A0pm, Andy <jonesa...@comcast.net> wrote: > Textbooks are seldom about state of the art in anything. Just because > they seem to be in unanimous agreement about one coding method does > not mean that the state of the art agrees. Two-process FSMs require > twice the declarations, require complex sensitivity lists, require > additional code to avoid latches, prohibit using variables to keep > local data local, thwart simulation optimizations that take advantage > of common sensitivity lists, and a host of other problems. > > There are two different practical issues at play here. One is whether > an output is a combinatorial function of just the state, and one is > whether the output is a also a combinatorial function of some > combinatorial inputs. > > The former can be mitigated by assigning registered outputs > "early" (i.e. when the FSM transitions to the state, not just when the > FSM is already in the state), or by assigning outputs from the state > variable after the clocked if statement ends. > > You appear to want the output to be the latter: a combinatorial > function of the registered state and of the unregistered inputs. > > While you can combine both into one process (with the combinatorial > input in the sensitivity list) as Mike has suggested, that is asking > for trouble, and if you don't correct the sensitivity list, then the > simulation and synthesis results will differ slightly, depending on > how/when the output is read by other processes/hardware. It is also > potentially prone to creating latches, to which a simple clocked > process is immune. > > You really should create this output in a separate process (or > concurrent assignment), but there is no need to separate the FSM into > two processes. > > The best way to avoid latches is to avoid combinatorial processes. > If you cannot avoid a combinatorial process, keep it as simple as > possible (doing only what has to be done combinatorially) and use up > front default assignments. > > I would suggest you look at your design requirements, and decide what > must be combinatorial, and what can tolerate a clock delay. > > Do you need to avoid =A0a clock delay between tx_valid and tx_data? > Do you need to avoid a clock delay between data_in and tx_data? > Do you need to avoid a clock delay between tx_ready and tx_data? > > Make sure you really need to avoid that clock delay. "It would be > better if..." does not count. A working design that is simple to > write, understand and maintain is much better than a design that is > none of those but happens to be a clock cycle faster. > > Find a way to accomplish combinatorially only what needs to be > combinatorial. It appears that tx_data is merely a function of > tx_valid, tx_ready, and data_in. What exactly do you need an FSM for? > You could use an FSM for error handling (what happens if tx_valid goes > high, then low, and tx_ready never fired?). But you don't appear to be > using it for that (maybe just to simplify the example?). > > Andy General rule of thumb is that for the very best performance, limit combinatorial block of logic to fanin that can be contained in one LUT of target FPGA fabric. The idea is that you can't go much faster than into one LUT-REG combination. For larger fanins, either use pipelining (for instance, one might have to pipeline large N-bit comparators into multiple clocked stages) or designer will have to rely on tool's efforts in keeping source/destination flops close to combinatorial implementation--at which time floorplanning (i.e. grouping) necessities may rear its ugly head. On FSMs, I don't think either one or two processes is "right" or "wrong." Each has its drawbacks. It is up to the hardware designer to adopt a style and routine of coding it right to meet project requirements. Over time, the designer will be able to draw up and debug that style very efficiently because of familiarity. JohnArticle: 149973
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 > based 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/developmentkits/xp2breviadevelopmentkit.cfm It is a small XP2 flash FPGA, about 5 or 6 kLUTs. But that is plenty enough to get started. It 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. One down side to this low priced kit is the lack of a real programming cable. They give you a parallel port cable, no doubt an ancient over-stock left from the dot com bubble 10 years ago. But 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. I find that pretty useful myself. RickArticle: 149974
On Dec 3, 7:32=A0am, saar drimer <saardri...@gmail.com> 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... > > =A0http://www.saardrimer.com/fpgaproj/ > > cheers, > saar. First some minuta. The figures aren't labeled, so it's hard to target comments for one. The first figure, "The 'flow'", doesn't have a "Build Scripts" as a source file type. I realize you had planned to make a distinction between scripts and source, but our build scripts are checked into our repository under the Philosophy that any checkout should be buildable as is, and we consider them part of our source. Also, testbenches should make mention of Unit Testing in hardware - it's automated and should be part of a mature build cycle. Scoping/ Tapping on the other hand is part of the development process so doesn't necessarily need to be mentioned here. I was in the study phase of implementing an SCons Builder/Scanner for XST/VHDL for my build cycles. Requiring that VHDL files share the entity name would make scanning dramatically easier; as I control our own internal standards I'll make this a requirement, along with configurations and components as well. You might consider requiring that source files fall under a directory with the same name as the library they're in. For example, if the entity Foo was part of library work, and Bar was part of library play, the directory structure look like so: ../Project/sources/hdl/work/Foo.vhd ../Project/sources/hdl/play/Bar.vhd We don't do any Verilog development so I'm not sure how the concept of a library is handled there. Another issue we have is that a lot of our sub-components should be accessible by some engineers, but not all engineers. By writing SCons SConstruct and SConscript files and using BuildBot, the idea was that an engineer could check in their sub-project and the server would initialize a build over the whole project while keeping components isolated to their respective developers. That is - our organizational issue is as follows: each component should have two levels of access - one public for declaration, one private for specification; if a team was designing an Ethernet controller we'd want the entity, component, configurations, behavioral simulations, and packages that define the types needed to interface with it to be available to everyone, while we'd want the implementation structure hidden. This would require a public/private fork of the directory structure under mercurial to accomplish, i.e. ../Project/public/source/hdl/work/Foo.vhd ../Project/private/source/hdl/work/Bar.vhd Then there would be a mercurial repository at Project, and public and private would be sub-repositories. Further, since mercurial allows pre and post hooks for all commands, the plan was to preempt any push to a stable repository on the server with an initiation of Unit Tests across the entire project (sub and sup modules...) that must be passed before it can successfully be pushed. The issue is that some modules will be used in multiple projects. We have yet to figure out the optimal method of doing this. I.E. Project1/submodules/Project3/... Project2/submodules/Project3/... Project3/... Pushes to Project3 should automatically initiate unit testing for Project1 and Project2. I have no clue how to do this effectively and efficiently. Overall though, I like the proposal. If I can make it fit my need for public/private portions of submodules I'll definitely use it. Thanks. ~Jonathan Ross
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