Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 149925

Article: 149925
Subject: SPI master controller with no embedded microprocessor
From: "andreiseb" <andrei.jacota@n_o_s_p_a_m.gmail.com>
Date: Thu, 02 Dec 2010 08:05:53 -0600
Links: << >>  << T >>  << A >>
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.com

Article: 149926
Subject: FSM single process...BIG question
From: "carlob" <carlo.beccia@n_o_s_p_a_m.libero.it>
Date: Thu, 02 Dec 2010 08:43:08 -0600
Links: << >>  << T >>  << A >>
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.com

Article: 149927
Subject: Re: Brain Cramps...
From: rickman <gnuarm@gmail.com>
Date: Thu, 2 Dec 2010 07:02:07 -0800 (PST)
Links: << >>  << T >>  << A >>
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.

Rick

Article: 149928
Subject: Re: Brain Cramps...
From: rickman <gnuarm@gmail.com>
Date: Thu, 2 Dec 2010 07:32:04 -0800 (PST)
Links: << >>  << T >>  << A >>
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.

Rick

Article: 149929
Subject: Re: Brain Cramps...
From: Jan Decaluwe <jan@jandecaluwe.com>
Date: Thu, 02 Dec 2010 16:32:22 +0100
Links: << >>  << T >>  << A >>
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: 149930
Subject: Re: Brain Cramps...
From: rickman <gnuarm@gmail.com>
Date: Thu, 2 Dec 2010 07:40:55 -0800 (PST)
Links: << >>  << T >>  << A >>
On 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.

Rick

Article: 149931
Subject: Re: What should I use for highspeed/low latency communication beteen
From: John Adair <g1@enterpoint.co.uk>
Date: Thu, 2 Dec 2010 08:56:16 -0800 (PST)
Links: << >>  << T >>  << A >>
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.com


Article: 149932
Subject: Re: SPI master controller with no embedded microprocessor
From: nico@puntnl.niks (Nico Coesel)
Date: Thu, 02 Dec 2010 18:47:39 GMT
Links: << >>  << T >>  << A >>
"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
Subject: Re: xilinx bitstream reading library & tool - legal issues?
From: Mike Treseler <mtreseler@gmail.com>
Date: Thu, 02 Dec 2010 10:56:51 -0800
Links: << >>  << T >>  << A >>
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: 149934
Subject: Re: Help help help on Huffman Encoder
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 2 Dec 2010 19:38:11 +0000 (UTC)
Links: << >>  << T >>  << A >>
kude <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.

-- glen

Article: 149935
Subject: Re: FSM single process...BIG question
From: Mike Treseler <mtreseler@gmail.com>
Date: Thu, 02 Dec 2010 11:46:37 -0800
Links: << >>  << T >>  << A >>
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: 149936
Subject: Re: Brain Cramps...
From: Mike Treseler <mtreseler@gmail.com>
Date: Thu, 02 Dec 2010 12:15:54 -0800
Links: << >>  << T >>  << A >>
On 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 Treseler


Article: 149937
Subject: Re: FSM single process...BIG question
From: rickman <gnuarm@gmail.com>
Date: Thu, 2 Dec 2010 12:16:55 -0800 (PST)
Links: << >>  << T >>  << A >>
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: 149938
Subject: Re: FSM single process...BIG question
From: Andy <jonesandy@comcast.net>
Date: Thu, 2 Dec 2010 14:38:52 -0800 (PST)
Links: << >>  << T >>  << A >>
On 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.

Andy

Article: 149939
Subject: Re: FSM single process...BIG question
From: Andy <jonesandy@comcast.net>
Date: Thu, 2 Dec 2010 14:46:45 -0800 (PST)
Links: << >>  << T >>  << A >>
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.

Andy

Article: 149940
Subject: Re: FSM single process...BIG question
From: Andy <jonesandy@comcast.net>
Date: Thu, 2 Dec 2010 14:49:59 -0800 (PST)
Links: << >>  << T >>  << A >>
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

Article: 149941
Subject: Re: FSM single process...BIG question
From: "carlob" <carlo.beccia@n_o_s_p_a_m.n_o_s_p_a_m.libero.it>
Date: Thu, 02 Dec 2010 17:33:12 -0600
Links: << >>  << T >>  << A >>
>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.com

Article: 149942
Subject: Re: Hi-Z Output Bug in Lattice ispLever
From: Alex <enginven@gmail.com>
Date: Thu, 2 Dec 2010 18:30:44 -0800 (PST)
Links: << >>  << T >>  << A >>
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 home

Article: 149943
Subject: Re: SPI master controller with no embedded microprocessor
From: backhus <goouse99@googlemail.com>
Date: Thu, 2 Dec 2010 23:18:31 -0800 (PST)
Links: << >>  << T >>  << A >>
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
  Eilert

Article: 149944
Subject: Re: Brain Cramps...
From: David Brown <david@westcontrol.removethisbit.com>
Date: Fri, 03 Dec 2010 09:11:57 +0100
Links: << >>  << T >>  << A >>
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
Subject: Opinions on Lattice ECP3
From: David Brown <david@westcontrol.removethisbit.com>
Date: Fri, 03 Dec 2010 09:45:51 +0100
Links: << >>  << T >>  << A >>
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





Article: 149946
Subject: Re: FSM single process...BIG question
From: Thomas Stanka <usenet_nospam_valid@stanka-web.de>
Date: Fri, 3 Dec 2010 01:05:00 -0800 (PST)
Links: << >>  << T >>  << A >>

> 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
Subject: Re: Opinions on Lattice ECP3
From: "Michael Kellett" <nospam@nospam.com>
Date: Fri, 3 Dec 2010 10:45:59 -0000
Links: << >>  << T >>  << A >>

"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 Kellett






Article: 149948
Subject: FPGA BOARD QUESTION
From: RealInfo <therightinfo@gmail.com>
Date: Fri, 3 Dec 2010 03:01:07 -0800 (PST)
Links: << >>  << T >>  << A >>
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


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

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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search