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
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 SPI 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 to 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 SPI 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! --------------------------------------- Posted through http://www.FPGARelated.comArticle: 149926
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... Thanx for any help Carlo --------------------------------------- Posted through http://www.FPGARelated.comArticle: 149927
On Dec 2, 5:14 am, David Brown <da...@westcontrol.removethisbit.com> wrote: > On 01/12/2010 19:36, rickman wrote: > > > On Dec 1, 12:20 pm, Jan Decaluwe<j...@jandecaluwe.com> wrote: > >> rickman wrote: > > >>> Yes, if "only full word match" is used, then "write_n" won't match a > >>> "write" search and replace so only "write" will change. > > >> It seems that you do not appreciate the difference between Rename > >> and global search and replace yet. > > >> The same identifier may refer to a lot of different objects in > >> a design. Rename is based on object identify, not identifier identity. > >> This makes it intelligent and safe. > > > Oh? How does that work. When can you use the same name for different > > objects??? Why would you if you can? > > I think the key to understanding here is that "search and replace" is a > purely textual function, while "rename" is a type of "refactoring". I > have no experience with this in VHDL, but I have used it a bit with C > programming (again using Eclipse). Calling it "refactoring" doesn't really help me understand what you are saying. > The point here is that Eclipse and the plugin (CDT for C or C++, Sigasi > for VHDL) analyses the syntax of the code - it effectively has the > front-end of a compiler for the language in question. It is not just a > matter of syntax highlighting based on regular expressions, as used by > most editors. It knows the difference between an entity called "write", > a signal called "write" and a function called "write" - because, like a > VHDL compiler, it knows the difference between these concepts. So you are saying that this tool will allow me to use the same name for an entity that I use for a signal and not get them confused when I change one of their names. I find that very unimportant. I never use the same names on entities that I use for signals and I'm not sure you can even do that in VHDL. I don't really care what the tools "know" and don't "know". I care about what that does for me. In this case it sounds like it does little that I would find interesting. I will say that if this stuff can be made to work in real time with reasonable error indications that are effective without being intrusive, then maybe it would be worthwhile. But there are the other issues to consider of it being a commercial product, support, cost and inflexibility of licensing. > Assuming Sigasi has similar functions to CDT, this will also allow fast > cross-linking of information between files. With CDT, you can hold your > mouse over an identifier and a tooltip will show you a short definition > of the identifier. You can navigate quickly to the definition of the > identifier, or to other uses of it. I do that pretty easily now for signals and variables. They are always declared in the same file. But this may be something that I would need to see in action to appreciate. > Whether or not you find this sort of thing useful is up to you. > Personally, I am using Eclipse more and more for C programming, though I > still like a simpler and faster text editor for many other tasks. > > There are other editors that can do a certain amount of refactoring, or > support the use of "tag" information for cross-navigation by identifier, > but I don't think anything else has the support Eclipse provides. > That's why a company like Sigasi has built a plugin for Eclipse - > Eclipse gives them a solid base for the refactoring, and they only need > to worry about the VHDL-specific part. It's also why - like it or not - > steadily more tool vendors are dropping their IDE's and editors and > moving to an Eclipse + plugin model. I haven't used refactoring much in my experience. I have used factoring and have found VHDL to be burdensome in that. Maybe I'll get a chance this winter to take a look at what Sigasi can do for me. To be honest, I don't bother too much with new tools unless I can be convinced they are worth looking at. In this case I might spend the time with the tool to see if it fits my hands. RickArticle: 149928
On Dec 2, 4:35 am, Martin Thompson <martin.j.thomp...@trw.com> wrote: > rickman <gnu...@gmail.com> writes: > > > Yes, if "only full word match" is used, then "write_n" won't match a > > "write" search and replace so only "write" will change. > > Here's a concrete example (to try and make the point I keep failing to > say clearly in a single sentence, sorry about that!): > > I have a FIFO with a write pin on it, and a memory with a write pin > on it. > > If I decide to change the FIFO to have an active low write, then I > rename the pin write_n. > > I've instantiated the FIFO and the memory a dozen times each in my > large project. > > If I do a global replace of "write" with "write_n" in the entire > project, all the references on the memory block will also change. If > I do an interactive global replace, I have to be really careful to get > it all right. Now, admittedly it's likely the compiler will catch it, > but I'll waste time sorting it all out. > > Sigasi just does it all for me. I get that. Maybe I have been coding "defensively" for long enough that this is not an issue for me. I wouldn't likely be changing a signal name in an interface like that. I might be changing the name of the signal used in this entity that connects to that signal in the interface, but I would have made it distinct to begin with. I often instantiate the same module more than once and the connecting signal names are extended to make them unique, ..._B1 ..._B2 for example. I appreciate what you are saying the tool can do, I guess this feature is just not that useful to me. > > Sorry, the evaluation of the tool ladder. I don't know how this tool > > is licensed, but I am very down on commercial tools because of the > > licensing issues and the seeming lack of support. That automatically > > puts a commercial tool below any open source tool when I am evaluating > > them. So the commercial tool has to be significantly better for me to > > want it. > > There's another aspect of the licensing which I forgot to mention - > it's based around Eclipse, which is an open-source IDE which supports > Java and C well out of the box (dunno about Forth :) - as a > replacement for CW on it's own Eclipse isn't bad (and if you end up > using Xilinx or Altera soft processors, their IDE is also > Eclipse-based). So the investment in Eclipse might be worth it > irrespective of Sigasi... [I still haven't quite made up my mind > whether to switch from Emacs to Eclipse for C-coding. It doesn't have > a Usenet reader like Gnus though, so I'll have to keep Emacs around > for a bit yet!] But how does Sigasi license their code? Do they trust their customers? Or is there something that can keep me from using the tool after some date or if I switch machines or the like? I currently only have one piece of software that has a license that can bring my work to a stop and that is the Lattice tools. I have a hard time remembering just how the licensing works and only use the tools sporadically. So it is once a year I try to use the tools and find they don't work because the license has expired and I have to ask for a new license file. I just went through this a month ago and the tool works, but it still reminds me that I haven't bought maintenance. I'm not sure if that means anything or is just a nag to get me to buy something. All of my other software, even if I've paid for it, is a version that does not need a key. Once I had to move a product to a new machine and couldn't find the original key for it. I tried to contact the company to get a copy of the key and they didn't respond. So I got a cracked version off the web somewhere and am happily back in business. > >> IIRC you start typing the first few chars and hit ctrl-space, and it > >> gives you a drop-down of potential completions. > > > And those completions include both keywords as well as your signal/ > > variable names? > > I think so yes (it's been a while since my eval) That might be worth something. I am a fast typist, but not accurate. I do very well filling in forms because of the auto-completion. The whole typing thing is a real bother. :-* > > If this feature works well enough I might consider > > Sigasi. Especially if it could be used for other languages than just > > VHDL. Is the VHDL aspect hard coded? I expect it will also support > > Verilog, but what about generic languages? Does it have a means of > > setting it up for an arbitrary language like CW does? > > Raw Eclipse deals with other languages, not Verilog though. > Completion works in C, for example, and the "go to declaration" type things. I can't remember the last time I did any C coding. I have moved to Forth. > It's another little thing that adds up :) Yes, little things can add up. I've spent enough time with this thread that I feel I've done the first day of eval with the tool. So maybe I'll get the demo at some point and give it a spin. > > I am considering designing a Radio Controlled Clock using a GA4 which > > would run off of two AAA cells for over a year. That should be a good > > demo of the low power capabilities, no? Would that make you believe > > that the chip can be pretty low power? The interesting part is that > > this can be done with the GA144 nearly as easily as the GA4, you just > > pay more to have 143 processors sitting idle 100% of the time and 1 > > processor idle 95% of the time. > > Or you could split the job up and have all 144 of them sitting idle > for 99.9% of the time :) Actually, splitting the job up will work best because of the limited code storage in each node. 64 words of ROM and 64 words of RAM. I think the F18B used in the GA4 will have 128 words of ROM and RAM. One node could operate the ADC, one node could provide a PLL to sync to the carrier, a third node demodulates the carrier and the fourth runs the clock based on the received radio data. They can directly execute instructions from an I/O port which can be SPI I believe (I may be mixing apples and oranges here, SPI and direct execution). So I think just one node can execute a Forth out of an SPI flash. This fourth node, programmed in high level Forth, can do all the low speed work processing the 1 bit per second radio data and running the clock. I'm also considering using a (fifth?) node to manage a switched cap power converter to optimize battery life. The limited I/ O count of the GA4 may not allow this. I see the limited memory as the biggest drawback to programming these chips. It will be interesting learning how to use them effectively. RickArticle: 149929
rickman wrote:
> On Dec 1, 12:20 pm, Jan Decaluwe <j...@jandecaluwe.com> wrote:
>> rickman wrote:
>>
>>> Yes, if "only full word match" is used, then "write_n" won't match a
>>> "write" search and replace so only "write" will change.
>> It seems that you do not appreciate the difference between Rename
>> and global search and replace yet.
>>
>> The same identifier may refer to a lot of different objects in
>> a design. Rename is based on object identify, not identifier identity.
>> This makes it intelligent and safe.
>
> Oh? How does that work. When can you use the same name for different
> objects???
Same name for a port on a different entity or component.
Same name for a formal argument of different functions.
Same name for a formal and an actual in a named association.
Same name that occurs in a comment string explanation.
Of course, I'm sure this is all obvious to you and I realize that
it must have been my explanation that was inadequate. But there
really was no need for this confusion. You could have seen all
these things for yourself by just spending one minute to see
the screencast. Sigh.
> Why would you if you can?
Because that's what we expect from an HDL, or any programming
language for that matter. Without it, no namespaces, no parametrization,
no hierarchy, no reuse.
Jan
--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Python as a HDL: http://www.myhdl.org
VHDL development, the modern way: http://www.sigasi.com
Analog design automation: http://www.mephisto-da.com
World-class digital design: http://www.easics.com
Article: 149930On Dec 2, 10:32 am, Jan Decaluwe <j...@jandecaluwe.com> wrote: > rickman wrote: > > On Dec 1, 12:20 pm, Jan Decaluwe <j...@jandecaluwe.com> wrote: > >> rickman wrote: > > >>> Yes, if "only full word match" is used, then "write_n" won't match a > >>> "write" search and replace so only "write" will change. > >> It seems that you do not appreciate the difference between Rename > >> and global search and replace yet. > > >> The same identifier may refer to a lot of different objects in > >> a design. Rename is based on object identify, not identifier identity. > >> This makes it intelligent and safe. > > > Oh? How does that work. When can you use the same name for different > > objects??? > > Same name for a port on a different entity or component. > Same name for a formal argument of different functions. > Same name for a formal and an actual in a named association. > Same name that occurs in a comment string explanation. > > Of course, I'm sure this is all obvious to you and I realize that > it must have been my explanation that was inadequate. But there > really was no need for this confusion. You could have seen all > these things for yourself by just spending one minute to see > the screencast. Sigh. I don't know what a screencast is and I have never seen a sales tool that conveyed any useful info in 1 minute. > > Why would you if you can? > > Because that's what we expect from an HDL, or any programming > language for that matter. Without it, no namespaces, no parametrization, > no hierarchy, no reuse. Maybe that's what you expect, but I avoid using the same name for different things. It causes a lot of confusion in debug. My current project uses the same UART code in the target FPGA as in the test bench. In simulation it can be hard to tell which UART XmitBuf I am looking at. I ended up using colors to distinguish their traces. Adding colors to traces in Active HDL is bit bothersome. It takes some five or more mouse clicks to set a color, even if I am only using two in the entire simulation. They need to have some sort of named format for the waveform display so it can be applied with just one or two mouse clicks. RickArticle: 149931
Real time control functions get harder to implement with every new generation of PC. Most of them now have a PCI Express backbone that gives a large variance in latency. Almost all data on a PC routes through this backbone so the problem of variance applies to anything hanging off it like a serial port or a USB port. Overall Latency has probably increased as well when compared to older PCs because of this packetised transmission structure. Generally any packet based interface like USB will have their own latency issues. Usually packets need a CRC check and so the complete packet has to be received and checked to do that. That gives latency. Same goes for PCI Express. The best way is to implement the real time stuff in your FPGA and use the PC itself as a supervisor, general storage and humun interface functions. For latency conventional PCI is probably still best but bear in mind there is almost certainly a PCI Express backbone in a modern PC. John Adair Enterpoint Ltd. On Nov 30, 3:05=A0pm, "Gravis" <fpgarelated@n_o_s_p_a_m.adaptivetime.com> wrote: > I have a FPGA project and it needs to interface with my PC. =A0The proble= m > I've run into is finding a fast form of communication with very low > latency. =A0I've come asking for advice and possible solution. > > I need a link that can transfer 1KB 1200 times every second, not just 1.2= MB > a second because the input is dependent on the output. =A0The latency iss= ue > makes USB impossible and a normal serial port doesnt have the bandwidth. > My initial inclination was to use a IEEE 1394 connection but the interfac= e > driver ICs are both expensive and too small to solder. =A0I've looked for= an > HDL implementation of the driver but I cannot find one. =A0Does anyone kn= ow > of a way to interface with a PC that can be or has been implemented on a > FPGA or has a low component count? > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.comArticle: 149932
"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 SPI >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 to >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 SPI >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? Look for Picoblaze (or pacoblaze). -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 149933
On 11/28/2010 3:08 PM, FlorianB82 wrote:
> why did you suggest me a drc system? sure, i could use it, but why?
Because hosting is often free for open source code.
> for veiling me as the author of the library?
No. The free repositories are open.
>> If you want the tired arguments, google this group.
> i did, but all i found was a mess of arguments, and beeing not familiar
> with such kind of things, some arguments sounded quite odd to me=). after
> all, this arguments are now a little bit old, and maybe something changed
> over the time...
Which is why I called them tired.
Good luck with your thesis.
-- Mike Treseler
Article: 149934kude <tadmas09@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote: > I tried and read a lot on how to construct huffman tree from a given > (Character,frequency) input and it is easy to do it on software but can't > get the idea on Hardware and pls give me a hint. This is exactly why hardware is different from software. In software, operations are serial. (Or, for multicore, some number of threads of serial operation, in parallel.) For hardware, you have to think about how fast something needs to be done, and how parallel it can, and should, be. The problem, which only you can answer, is what hardware vs. speed tradeoff is needed. How many clock cycles are available per input character? The hardware can be designed bit serial, such that one (hopefully fast) clock cycle is used per input bit. For finite (and known in advance) input width, it can be done fully parallel, such that the whole output comes out one (long) clock cycle later. That latter is usually called combinatorial, though there is likely a latch before and after the logic block. Usually it will be somewhere in between, and exactly where you have to figure out. It is a tradeoff between logic used and speed, sometimes made without knowing all the parameters. You could crosspost to comp.compression, where Huffman might be discussed, but not FPGAs. If you give some of the requirements, such as input and output speed, data (character) width, and such, we might be able to suggest something. Otherwise, you might look at the systolic array architecture, though I am not completely sure that it can be done that way. > 1)on how to make sort (synthesizable) and construct huffman tree I believe the usual one is to generate, and use, the tree as data is being processed. That is, dynamic tree. In that case, the important part is that the encoder tree stays synchronized with the decoder tree, not that each is optimal for the given input. > 2)How to read the codeword from the tree A lookup table? Maybe a hash table. -- glenArticle: 149935
On 12/2/2010 6:43 AM, carlob wrote:
> I've a problem to efficiently unregister output from FSM written in a
> single process style...
> I've read something about using variables...but I don't understand exactly
> how...please show me an example...
For such a simple case, you could more quickly rewrite the code.
If you are interested in using vhdl variables, and have some spare time,
here is how I do it:
begin -- process template
if reset = '1' then -- Assumes synched trailing edge reset
init_regs; -- reg_v := init_c; No port init required
elsif rising_edge(clock) then
update_regs; -- reg_v := f(in, var)
-- no port update need here
end if; --
update_ports; -- out_port <= reg_v; -- sync outputs
-- out_port <= f(in, var) -- asych out
end process sync_template; -- will infer port wires ok rst or clk
end architecture synth;
Details here:
http://mysite.ncnetwork.net/reszotzl/sync_template.vhd
http://mysite.ncnetwork.net/reszotzl
Good luck
-- Mike Treseler
Article: 149936On 11/30/2010 6:31 AM, rickman wrote: > I also spend time designing the > boards, writing test code, specs, docs and even conversing with > customers... oh yeah, and that slightly important part, looking for > customers. Until the tide turns, this is everyone's problem. -- Mike TreselerArticle: 149937
On Dec 2, 9:43=A0am, "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 =3D '1') then
> next_state <=3D START;
> if (pluto =3D '1') then
> outp <=3D '0';
> else
> outp <=3D '1';
> end if;
> end if;
>
> outp is registered...if I want to avoid that register I should (in anothe=
r
> process) duplicate a lot of logic:
>
> if (state =3D IDLE) then
> if (pippo =3D '1' and pluto =3D '1') then
> outp <=3D '0'
> elsif (pippo =3D '1' and pluto =3D '0') then
> outp <=3D '1';
> else outp <=3D '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 exactl=
y
> 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 =3D '1') then
next_state <=3D START;
if (pluto =3D '1') then
outp <=3D '0';
else
outp <=3D '1';
end if;
end if;
...
end process StateLogicPrc;
StateRegPrc: process (rst, clk) begin
if (rst =3D '1') then
CurState <=3D StartingState;
elsif (rising_edge(clk)) then
CurState <=3D 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
Article: 149938On Dec 2, 1:46=A0pm, Mike Treseler <mtrese...@gmail.com> wrote: > On 12/2/2010 6:43 AM, carlob wrote: > > > I've a problem to efficiently unregister output from FSM written in a > > single process style... > > I've read something about using variables...but I don't understand exac= tly > > how...please show me an example... > > For such a simple case, you could more quickly rewrite the code. > > If you are interested in using vhdl variables, and have some spare time, > here is how I do it: > > =A0 =A0 begin =A0-- process template > =A0 =A0 =A0 =A0if reset =3D '1' then =A0 =A0 -- Assumes synched trailing = edge reset > =A0 =A0 =A0 =A0 =A0 init_regs; =A0 =A0 =A0 =A0 =A0 -- reg_v :=3D init_c; = No port init required > =A0 =A0 =A0 =A0elsif rising_edge(clock) then > =A0 =A0 =A0 =A0 =A0 update_regs; =A0 =A0 =A0 =A0 -- reg_v :=3D f(in, var) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- no port= update need here > =A0 =A0 =A0 =A0end if; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- > =A0 =A0 =A0 =A0update_ports; =A0 =A0 =A0 =A0 =A0 -- out_port <=3D reg_v; = =A0 =A0 -- sync outputs > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- out_por= t <=3D f(in, var) -- asych out > =A0 =A0 end process sync_template; -- will infer port wires ok rst or clk > end architecture synth; > > Details here:http://mysite.ncnetwork.net/reszotzl/sync_template.vhdhttp:/= /mysite.ncnetwork.net/reszotzl > > Good luck > =A0 =A0 =A0-- Mike Treseler Note that while out_port <=3D f(in, var), located after the clk/rst end if statement, will produce combinatorial logic from in to out_port (or out_sig), the simulation and synthesis will mismatch slightly. Outport will only be updated on any event of clk or rst (i.e. both edges of both) in simulation, but continously in hardware (i.e. any edge of in). Whether this makes a difference is dependent upon what is reading the out_port. This can be avoided by adding any "in" signals used as such to the process sensitivity list. If pluto is an input to the process, then the only way to do it and retain the sim/hw matching behavior for all cases is to use a separate combinatorial process. I generally do not like combinatorial paths from in to out within a state machine, and will seek to implement it in a register if at all possible. Combinatorial processes, especially ones as complex as state machines with nested case & if statements, are prone to create latches. Avoid the combinatorial process, and avoid the possibility of a latch. If you cannot avoid the combinatorial process, then at least add default assignments for all output signals in the very beginning of the process, before any conditional statements are executed. This is much easier to write, and to review/audit, than the old addage to include an else for every if, etc. AndyArticle: 149939
On Dec 2, 2:16=A0pm, rickman <gnu...@gmail.com> wrote: > On Dec 2, 9:43=A0am, "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 =3D '1') then > > next_state <=3D START; > > if (pluto =3D '1') then > > outp <=3D '0'; > > else > > outp <=3D '1'; > > end if; > > end if; > > > outp is registered...if I want to avoid that register I should (in anot= her > > process) duplicate a lot of logic: > > > if (state =3D IDLE) then > > if (pippo =3D '1' and pluto =3D '1') then > > outp <=3D '0' > > elsif (pippo =3D '1' and pluto =3D '0') then > > outp <=3D '1'; > > else outp <=3D '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 exac= tly > > how...please show me an example... > > You might find it easier to separate the state machine from the state > register. =A0Then 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. =A0The > 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. =A0The clocked > process just defines the CurState register in terms of the NxtState > signal. =A0The clocked process is idiot simple and so does not duplicate > the code that you are worried about. > > StateLogicPrc: process (CurState, pippo, pluto,...) begin > =A0 -- if (rising_edge(clk)) then =A0-- remove this sequential stuff from > the process > =A0 -- so you are just left with the logic... > =A0 case CurState is > =A0 =A0 when IDLE: > =A0 =A0 =A0 if (pippo =3D '1') then > =A0 =A0 =A0 =A0 next_state <=3D START; > =A0 =A0 =A0 =A0 if (pluto =3D '1') then > =A0 =A0 =A0 =A0 =A0 outp <=3D '0'; > =A0 =A0 =A0 =A0 else > =A0 =A0 =A0 =A0 =A0 outp <=3D '1'; > =A0 =A0 =A0 =A0 end if; > =A0 =A0 =A0 end if; > ... > end process StateLogicPrc; > > StateRegPrc: process (rst, clk) begin > =A0 if (rst =3D '1') then > =A0 =A0 CurState <=3D StartingState; > =A0 elsif (rising_edge(clk)) then > =A0 =A0 CurState <=3D next_state; > =A0 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. =A0Now 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. AndyArticle: 149940
Carlo, You may already know this, but... Your combinatorial process is not equivalent to the clocked process. An unassigned signal is not driven to 'Z'; it creates a latch. Read below for more information. If this was just an unfortunate choice of "for example" please disregard. AndyArticle: 149941
>Carlo, > >You may already know this, but... > >Your combinatorial process is not equivalent to the clocked process. >An unassigned signal is not driven to 'Z'; it creates a latch. Read >below for more information. > >If this was just an unfortunate choice of "for example" please >disregard. > >Andy > Hi, first of all...thanx for your help.... The question is...basically in a case like that is better to use 2 process method...is it right?? I'm studing vhdl by myself and on every textbook I've found around the best way to code FSM is 2 process... I started writing my code (in 2 process style)...but, taking a look at code written by others I see very often only 1 process...crazy... I tried to implement some part in 1 process style because it seems to me more "simple"..cleaner...but the output is registered and doesn't fit well with rest of the code (other FSM)... I've started to ask me if there is a method to implement in a 1 process unregistered output FSM... I've tried something like this: variable v_tx_data : std_logic_vector(7 downto 0); begin if (reset='1') then act_txd_state <= TXD_IDLE; v_tx_data := (others => '0'); elsif (clk'event and clk ='1') then case act_txd_state is when TXD_IDLE => if (txValid = '1') then if (dataIn = "00000000") then v_tx_data := "01000000"; else v_tx_data := "11000000"; end if; act_txd_state <= TXD_ACTIVE; end if; when TXD_ACTIVE => if (txReady = '1') then act_txd_state <= TXD_END; end if; when TXD_END => v_tx_data := dataIn; if (txValid = '0') then act_txd_state <= TXD_IDLE; end if; end case; end if; tx_data <= v_tx_data; Obviously v_tx_data is a FF...and the output is registered....I don't find any way to unregister output in a process like that... Any hint?? Mike in you example output is registered or not?? eventually...how can I apply your 1 process example to the above code??? 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??? Thanx Carlo --------------------------------------- Posted through http://www.FPGARelated.comArticle: 149942
On Dec 1, 1:01=A0pm, rickman <gnu...@gmail.com> wrote: > On Dec 1, 2:09=A0pm, Alex <engin...@gmail.com> wrote: > > > > > On Nov 30, 6:11=A0pm, rickman <gnu...@gmail.com> wrote: > > > > On Nov 30, 9:58 am, Gabor <ga...@alacron.com> wrote: > > > > > On Nov 30, 8:46 am, rickman <gnu...@gmail.com> wrote: > > > > > > On Nov 30, 2:35 am, Newman <newman5...@yahoo.com> wrote: > > > > > > > On Nov 29, 11:54 pm, rickman <gnu...@gmail.com> wrote: > > > > > > > > I'm not sure what is wrong here. I have a design that I have = used in > > > > > > > the past and has worked ok. I am making modifications to it a= nd my Hi- > > > > > > > Z outputs are being grounded. This creates some problems duri= ng > > > > > > > operation. The VHDL code is like this... > > > > > > > > TMS_B1 <=3D 'Z'; > > > > > > > > I just want this output to be Hi-Z for this design so that th= e pin > > > > > > > output is not driven (which clobbers these signals from other > > > > > > > sources). The lines for this output in the preference file ar= e... > > > > > > > > LOCATE COMP "TMS_B1" SITE "36" ; > > > > > > > IOBUF PORT "TMS_B1" IO_TYPE=3DLVCMOS33 PULLMODE=3DKEEPER DRIV= E=3D8 > > > > > > > SLEWRATE=3DSLOW ; > > > > > > > > When I load the design into the part, the output is always lo= w and > > > > > > > checking the design in Epic, I see the tri-state driver has a= 0 on the > > > > > > > input and a 0 on the enable. I believe the 0 on the enable tu= rns on > > > > > > > the output driver because that is how the outputs are configu= red. > > > > > > > > I also looked at the Technology View in Synplify and I find T= MS_B1 is > > > > > > > driven by a OB with a 0 on it's input. > > > > > > > > Is this a bug or is there something wrong with the way I am d= oing > > > > > > > this? I made a lot of changes to the overall design before I > > > > > > > discovered this bug so I'm not certain that the preference fi= le lines > > > > > > > have not been changed since this was working, but I don't see= how they > > > > > > > can be causing this problem. > > > > > > > > Rick > > > > > > > Rick, > > > > > > I suppose you have already convinced yourself that it is not th= e > > > > > > buskeeper circuit driving the line low. > > > > > > > Bus Maintenance Circuit > > > > > > Each pad has a weak pull-up, weak pull-down and weak buskeeper > > > > > > capability. The pull-up and pull-down settings > > > > > > offer a fixed characteristic, which is useful in creating wired= logic > > > > > > such as wired ORs. However, current can be > > > > > > slightly higher than other options, depending on the signal sta= te. The > > > > > > bus-keeper option latches the signal in the > > > > > > last driven state, holding it at a valid level with minimal pow= er > > > > > > dissipation. Users can also choose to turn off the bus > > > > > > maintenance circuitry, minimizing power dissipation and input l= eakage. > > > > > > Note that in this case, it is important to > > > > > > ensure that inputs are driven to a known state to avoid unneces= sary > > > > > > power dissipation in the input buffer. > > > > > > Thanks for the suggestion, but yes, I eliminated that by looking = at > > > > > the I/O block settings in Epic, the layout editor. =A0I originall= y saw > > > > > this problem with an LED driving pin. =A0I set it for hi-z and it= was > > > > > driving the LED on hard. =A0A bus keeper wouldn't drive that hard= . > > > > > Besides, this pin is driving two LEDs, one up and one down. =A0Hi= -z is > > > > > the only state where neither LED is on. =A0When I use logic to se= lect > > > > > the three states, 1, 0, Z; then the hi-z state is enabled > > > > > appropriately. > > > > > > I can always work around this by controlling it from some signal = such > > > > > as reset so that it is always hi-z after the FPGA is up. =A0It is= odd > > > > > that this worked just fine before and now screws up. =A0I haven't > > > > > updated any of the development software that I know of, but I hav= en't > > > > > messed with this design since 2008, so there's been a lot of wate= r > > > > > under the dam since then. =A0If it is a tool problem, I may not g= et an > > > > > update. =A0My maintenance ran out long ago and this is a paid for= copy. > > > > > I'd hate to have to shell out a kilobuck to get a bug fix so I ca= n > > > > > continue using the software that I already paid for. > > > > > > Rick > > > > > This looks remarkably like something I remember from older Xilinx > > > > projects where assigning an output to 'Z' effectively removed it fr= om > > > > the > > > > design. =A0(the output isn't "driven" so get rid of it) =A0Then the > > > > default > > > > action for the backend tools is to take any undriven outputs and > > > > ground them (you must have forgotten to assign a value to this). > > > > > What would happen if you changed the output so it is only tristate > > > > under some condition? =A0You could pick some condition that you > > > > know is always true, but the synthesizer can't guess, or make the > > > > output briefly drive (high or low) as the design comes out of reset= . > > > > > Does your project perhaps have a setting or unused IOB's to > > > > be "virtual grounds"? > > > > > All I can think of... > > > > > -- Gabor > > > > Hi Gabor. =A0I also have outputs driving pairs of LEDs that are > > > conditional and can be either '0', '1' or 'Z'. =A0They work just fine= . > > > In fact, I first saw this on LED drive outputs that I drove with a > > > 'Z'. =A0The red LEDs came on which means it was pulled hard to ground= . > > > I turned off the buskeeper mode and it still drove the output hard to > > > ground. =A0That was when I first looked at the design in Epic and saw > > > the tri-state control driven to a fixed '0' instead of a fixed '1', > > > like it is now! =A0If I hadn't see this before, it would have been te= n > > > times harder to figure out what was keeping my programming cable from > > > working with by target boards! =A0These JTAG signals are also connect= ed > > > to the test fixture FPGA in case I get to the point where I want the > > > FPGA to program the target boards instead of using the Lattice > > > software. =A0Oddly enough, Lattice cautions you against using the USB > > > cable for production programming. =A0I guess this is just a CYA thing= in > > > case it doesn't work correctly and you ship 10,000 boards that aren't > > > programmed right... "don't come back to us"! > > > > I had considered controlling the tri-states with some signal that > > > would not conflict with an external driver of the JTAG signals, such > > > as the GSR or maybe a switch input. =A0But the issue seems to have > > > resolved itself. =A0I'm not sure I will ever know what was wrong unle= ss > > > it returns. =A0I know the preference file gets rewritten each time I = run > > > the tool, but I can't say the file actually changes. =A0I haven no id= ea > > > why it has to write the file back out each time. =A0The only thing it > > > seems to change is when I put a title block at the head of the file, > > > the tools keep writing the line, "COMMERCIAL;" just in front of it. > > > No matter where I put this line in the file, it gets moved to the > > > first line. > > > > If nothing else, it helps to have others make suggestions. =A0It can = be > > > easier to figure things out when you have to explain something and > > > think about other's comments. =A0Thanks. > > > > Rick > > > Rick, > > > It is odd, and I completely understand your frustration. To analyze > > why this happened, one will need your whole project data-base and I'll > > have to ask you to engage your local FAE, if you decide to go this > > way... > > > Also if it is a bug in the SW, then very possibly you won't see it in > > a later release =A0(the release 7.2 SP2 you're using is two revs behind= , > > we have ispLever 8.1 sp1 now and also the new Diamond SW). > > > The good news is that you can use Lattice free Starter SW to support > > the part you're using (all Lattice non-volatile families are fully > > covered by the free SW option, you'll need non-free SW only for FPGA > > with multi-GB transceivers -SERDES's in Lattice terminology). So I'd > > suggest to download the latest ispLever Starter SW and try to use it. > > > Another thing that I wanted to mention is that you can also try to use > > the free version of Lattice new Diamond SW. The point tools are the > > same but the GUI is considerably improved (and, of course changed...). > > We're getting quite positive feedback from all the customers who tried > > the new SW. > > Hi Alex, Thanks again for the reply. =A0I likely won't pursue this > unless the symptom returns. > > I have never really understood what is provided with what versions of > the software. =A0The reason that I paid for a copy two years (or more) > ago was because the simulation was not included with the free > versions. =A0Is that no longer true? =A0Can I simulate my designs with th= e > starter package now? =A0If so, I guess I don't need to keep my paid for > package and can switch to the free, but up to date tools. > > Rick Hi Rick, Lattice Web Edition version of Aldec Active HDL simulator is provided with free tools. The free simulator has two limitations compared to a paid-for version of the simulator (Active HDL Lattice Edition): - the size of the simulated design including the test-bench must be less than 5000 lines - only one HDL (user can chose VHDL or Verilog) is supported. Paid-for version supports both VHDL and Verilog, i.e. full-fledged mix-language simulation. For not very big designs not requiring mix-language simulations these are reasonable constraints. And, of course, one can separately simulate parts of a design. Currently Lattice is using a yearly subscription (paid-for) license. During the year a user will receive all the current updates, upgrades (and bug fixes) and full SW support. Let me know if you'll need additional information. Alex Lattice FAE, writing from homeArticle: 149943
On 2 Dez., 15:05, "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 Hi, using something small like the picoblaze is a good idea, since it is a flexible solution. But you asked for something different. Of course a simple dedicated FSM can do the job too. Depending on the builtin "intelligence" of the SPI Interface the needed complexity varies. The FSM needs to know somehow that new data has arrived, and then perform the neccessary steps to transfer this data from the SPI Register to the RAM (or FIFO, which is simpler). Then it waits for the next data, or initiates sending some data/ command that triggers the peripheral device to return more data. Whatever is intended. You have to decide which solution fits best for your application. Have a nice synthesis EilertArticle: 149944
On 02/12/2010 16:02, rickman wrote: > On Dec 2, 5:14 am, David Brown<da...@westcontrol.removethisbit.com> > wrote: >> On 01/12/2010 19:36, rickman wrote: >> >>> On Dec 1, 12:20 pm, Jan Decaluwe<j...@jandecaluwe.com> wrote: >>>> rickman wrote: >> >>>>> Yes, if "only full word match" is used, then "write_n" won't match a >>>>> "write" search and replace so only "write" will change. >> >>>> It seems that you do not appreciate the difference between Rename >>>> and global search and replace yet. >> >>>> The same identifier may refer to a lot of different objects in >>>> a design. Rename is based on object identify, not identifier identity. >>>> This makes it intelligent and safe. >> >>> Oh? How does that work. When can you use the same name for different >>> objects??? Why would you if you can? >> >> I think the key to understanding here is that "search and replace" is a >> purely textual function, while "rename" is a type of "refactoring". I >> have no experience with this in VHDL, but I have used it a bit with C >> programming (again using Eclipse). > > Calling it "refactoring" doesn't really help me understand what you > are saying. > > >> The point here is that Eclipse and the plugin (CDT for C or C++, Sigasi >> for VHDL) analyses the syntax of the code - it effectively has the >> front-end of a compiler for the language in question. It is not just a >> matter of syntax highlighting based on regular expressions, as used by >> most editors. It knows the difference between an entity called "write", >> a signal called "write" and a function called "write" - because, like a >> VHDL compiler, it knows the difference between these concepts. > > So you are saying that this tool will allow me to use the same name > for an entity that I use for a signal and not get them confused when I > change one of their names. I find that very unimportant. I never use > the same names on entities that I use for signals and I'm not sure you > can even do that in VHDL. > Fair enough. Different people work in different ways, and some people don't have full control over all the code - they are working with code from other people. It is always a nice rule to avoid using the same name for different things. I can't say I've used the renaming refactoring in C programming with Eclipse either - I'm just trying to explain the difference from a purely textual search-and-replace, rather than to persuade you to /use/ the feature! > I don't really care what the tools "know" and don't "know". I care > about what that does for me. In this case it sounds like it does > little that I would find interesting. I will say that if this stuff > can be made to work in real time with reasonable error indications > that are effective without being intrusive, then maybe it would be > worthwhile. But there are the other issues to consider of it being a > commercial product, support, cost and inflexibility of licensing. > > >> Assuming Sigasi has similar functions to CDT, this will also allow fast >> cross-linking of information between files. With CDT, you can hold your >> mouse over an identifier and a tooltip will show you a short definition >> of the identifier. You can navigate quickly to the definition of the >> identifier, or to other uses of it. > > I do that pretty easily now for signals and variables. They are > always declared in the same file. But this may be something that I > would need to see in action to appreciate. > Again, I've only used it with C programming - and there it definitely /is/ useful. But it also depends on things like the size of the project, the organisation, whether you have written everything yourself, and whether you are just patching up old code or working concentrated on the project. If you have a solid overview of all the identifiers in your head, you don't need to look them up. > >> Whether or not you find this sort of thing useful is up to you. >> Personally, I am using Eclipse more and more for C programming, though I >> still like a simpler and faster text editor for many other tasks. >> >> There are other editors that can do a certain amount of refactoring, or >> support the use of "tag" information for cross-navigation by identifier, >> but I don't think anything else has the support Eclipse provides. >> That's why a company like Sigasi has built a plugin for Eclipse - >> Eclipse gives them a solid base for the refactoring, and they only need >> to worry about the VHDL-specific part. It's also why - like it or not - >> steadily more tool vendors are dropping their IDE's and editors and >> moving to an Eclipse + plugin model. > > I haven't used refactoring much in my experience. I have used > factoring and have found VHDL to be burdensome in that. Maybe I'll > get a chance this winter to take a look at what Sigasi can do for me. > To be honest, I don't bother too much with new tools unless I can be > convinced they are worth looking at. In this case I might spend the > time with the tool to see if it fits my hands. > Well, I leave it to the people with connection to or experience with Sigasi to do the persuading. I'm just trying to help explain a couple of features, so that you (and others reading this) can get a better idea of what the tool can do that a simpler text editor cannot.Article: 149945
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., DavidArticle: 149946
> 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';Article: 149947
"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. 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 !). I think your projects sound a bit bigger than mine so your experience may be different. Michael KellettArticle: 149948
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 ECArticle: 149949
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
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