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

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

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

Custom Search

Messages from 147175

Article: 147175
Subject: Re: I'd rather switch than fight!
From: Bernd Paysan <bernd.paysan@gmx.de>
Date: Fri, 16 Apr 2010 20:24:47 +0200
Links: << >>  << T >>  << A >>
rickman wrote:
> People say that strong typing catches bugs, but I've never seen any
> real proof of that.  There are all sorts of anecdotal evidence, but
> nothing concrete.

My practical experience is that strong typing creates another class of bugs, 
simply by making things more complicated.  I've last seen VHDL in use more 
than 10 years ago, but the typical pattern was that a designer wanted a bit 
vector, and created a subranged integer instead.  Seems to be identical, but 
isn't.  If you increment the subranged integer, it will stop simulation on 
overflow, if you increment the bit vector, it will wrap around.  My coworker 
who did this subranged integer stuff quite a lot ended up with code like

if foo = 15 then foo <= 0 else foo <= foo + 1 endif;

And certainly, all those lines had started out as

foo <= foo + 1;

and were only "fixed" later when the simulation crashed.

The good news is that the synthesis tool really generates the bitvector 
logic for both, so all those simulator crashes were only false alarms.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself!"
http://www.jwdt.com/~paysan/

Article: 147176
Subject: Re: I'd rather switch than fight!
From: rickman <gnuarm@gmail.com>
Date: Fri, 16 Apr 2010 11:25:51 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 15, 5:48=A0pm, Patrick Maupin <pmau...@gmail.com> wrote:
> On Apr 15, 4:31=A0pm, Muzaffer Kal <k...@dspia.com> wrote:
>
>
>
> > On Thu, 15 Apr 2010 14:21:37 -0700 (PDT), Patrick Maupin
>
> > <pmau...@gmail.com> wrote:
> > >On Apr 15, 3:12=A0pm, David Brown <da...@westcontrol.removethisbit.com=
>
> > >wrote:
>
> > >> Another famous contest involved a C and Ada comparison. =A0It took t=
he Ada
> > >> more than twice as long as the C team to write their code, but it to=
ok
> > >> the C team more than ten times as long to debug their code.
>
> > >Well, this isn't at all the same then. =A0The Verilog teams got workin=
g
> > >designs, and the VHDL teams didn't.
>
> > There are two issues to consider. One is the relative times of writing
> > the codes vs debugging ie if writing took 5 hours and debugging 10
> > minutes (unlikely) then C still wins. Which brings the second issue:
> > it is very likely that the programming contest involved a "larger"
> > design to be finished. If I am remembering correctly RTL was =A0an asyn=
c
> > reset, synchronously loadable up-down counter which is a "smallish"
> > project. If programming contest involved something more "involved" it
> > still points to the benefit of strong typing and other features of
> > Ada/VHDL etc.
>
> But it's mostly academic and FPGA people who think that VHDL might
> have any future at all. =A0See, for example:
>
> http://www.eetimes.com/news/design/columns/industry_gadfly/showArticl...
>
> Regards,
> Pat

Hmmm...  The date on that article is 04/07/2003 11:28 AM EDT.  Seven
years later I still don't see any sign that VHDL is going away... or
did I miss something?

Rick

Article: 147177
Subject: Re: I'd rather switch than fight!
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 16 Apr 2010 18:32:56 +0000 (UTC)
Links: << >>  << T >>  << A >>
In comp.arch.fpga rickman <gnuarm@gmail.com> wrote:
(snip, I wrote)
>> Seatbelts may save lives, but statistically many other safety
>> improvements don't. ?When people know that their car has air bags,
>> they compensate and drive less safely. ?(Corner a little faster, etc.)
>> Enough to mostly remove the life saving effect of the air bags.
 
> Are you making this up?  I have never heard that any of the other
> added safety features don't save lives overall.  I have heard that
> driving a sportier car does allow you to drive more aggressively, but
> this is likely not actually the result of any real analysis, but just
> an urban myth.  Where did you hear that air bags don't save lives
> after considering all?

I believe that they still do save lives, but by a smaller
factor than one might expect.  I believe the one that I saw
was not quoting air bags, but anti-lock brakes.  

The case for air bags was mentioned by someone else -- that some
believe that they don't need seat belts if they have air bags.
Without seat belts, though, you can be too close to the air bag
when it deploys, and get hurt by the air bag itself.  For that 
reason, they now use slower air bags than they used to.

The action of anti-lock breaks has a more immediate feel while
driving, and it seems likely that many will take that into account
while driving.  I believe that there is still a net gain, but
much smaller than would be expected.

-- glen

Article: 147178
Subject: Re: I'd rather switch than fight!
From: rickman <gnuarm@gmail.com>
Date: Fri, 16 Apr 2010 11:35:54 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 16, 5:38=A0am, David Brown <da...@westcontrol.removethisbit.com>
wrote:
> Secondly, a testbench does not check everything. =A0It is only as good as
> the work put into it, and can be flawed in the same way as the code
> itself. =A0

I was listening to a lecture by a college once who indicated that you
don't need to use static timing analysis since you can use a timing
based simulation!  I queried him on this a bit and he seemed to think
that you just needed to have a "good enough" test bench.  I was
incredulous about this for a long time.  Now I realize he was just a
moron^H^H^H^H^H^H^H ill informed!

Rick

Article: 147179
Subject: Re: I'd rather switch than fight!
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 16 Apr 2010 18:45:03 +0000 (UTC)
Links: << >>  << T >>  << A >>
In comp.arch.fpga rickman <gnuarm@gmail.com> wrote:
(snip)
 
> I was listening to a lecture by a college once who indicated that you
> don't need to use static timing analysis since you can use a timing
> based simulation!  I queried him on this a bit and he seemed to think
> that you just needed to have a "good enough" test bench.  I was
> incredulous about this for a long time.  Now I realize he was just a
> moron^H^H^H^H^H^H^H ill informed!

I suppose so, but consider it the other way around.

If your test bench is good enough then it will catch all static
timing failures (eventually).  With static timing analysis, there
are many things that you don't need to check with the test bench.

Also, you can't do static timing analysis on the implemented logic.
(That is, given an actual built circuit and a logic analyzer.)

Now, setup and hold violations are easy to test with static
analysis, but much harder to check in actual logic.  Among others,
you would want to check all possible clock skew failures, which is
normally not possible.  With the right test bench and logic
implementation (including programmable delays on each FF clock)
it might be possible, though.

-- glen

Article: 147180
Subject: Re: I'd rather switch than fight!
From: Bernd Paysan <bernd.paysan@gmx.de>
Date: Fri, 16 Apr 2010 20:56:19 +0200
Links: << >>  << T >>  << A >>
Andy wrote:
> IMHO, they missed the point. Any design that can be completed in a
> couple of hours will necessarily favor the language with the least
> overhead. Unfortunately, two-hour-solvable designs are not
> representative of real life designs, and neither was the contest's
> declared winner.

Well, we pretty much know that the number of errors people make in 
programming languages basically depends on how much code they have to write 
- a language which has less overhead and is more terse is being written 
faster and has less bugs.  And it goes non-linear, i.e. a program with 10k 
lines of code will have less bugs per 1000 lines than a program with 100k 
lines of code.  So the larger the project, the better the more terse 
language is.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself!"
http://www.jwdt.com/~paysan/

Article: 147181
Subject: Changing output pins slew&drive strength without re-run ISE
From: Mawa_fugo <ccon67@netscape.net>
Date: Fri, 16 Apr 2010 12:16:38 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi all,
Is there anyway to modify bit file just to change I/O slew rate &
drive strength without re-run ISE processes ?

TIA & TGIF

Article: 147182
Subject: Re: Changing output pins slew&drive strength without re-run ISE
From: Gabor <gabor@alacron.com>
Date: Fri, 16 Apr 2010 13:32:43 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 16, 3:16=A0pm, Mawa_fugo <cco...@netscape.net> wrote:
> Hi all,
> Is there anyway to modify bit file just to change I/O slew rate &
> drive strength without re-run ISE processes ?
>
> TIA & TGIF

The easiest way is to use the FPGA editor to modify the
settings (find your IOB in the "components" list and
then use "editblock").  Then save the file and just
re-run bitgen.

Regards,
Gabor

Article: 147183
Subject: Re: I'd rather switch than fight!
From: Patrick Maupin <pmaupin@gmail.com>
Date: Fri, 16 Apr 2010 14:08:17 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 16, 12:58=A0pm, rickman <gnu...@gmail.com> wrote:

> That is certainly a great way to prove a theory. =A0Toss out every data
> point that disagrees with your theory!

Well, I don't really need others to agree with my theory, so if that's
how it's viewed, so be it.  Nonetheless, I view it as tossing out data
that was taken under different conditions than the ones I live under.
Although the basics don't change (C, C++, Java, Verilog, VHDL are all
turing-complete, as are my workstation and the embedded systems I
sometimes program on), the details can make things qualitatively
enough different that they actually appear to be quantatively
different.  It's like quantum mechanics vs. Newtonian physics.

For example, on my desktop, if I'm solving an engineering problem, I
might throw Python and numpy, or matlab, and gobs of RAM and CPU at
it.  On a 20 MIPS, fixed point, low-precision embedded system with a
total of 128K memory, I don't handle the problem the same way.

I find the same with language differences.  I assumed your complaint
when you started this thread was that a particular language was
*forcing* you into a paradigm you felt might be sub-optimal.  My
opinion is that, even when languages don't *force* you into a
particular paradigm, there is an impedance match between coding style
and language that you ignore at the peril of your own frustration.

So when somebody says " I don't change the way I code when I code in
Verilog vs. VHDL
or C vs. Java, the compiler just does a better job of catching my
stupid mistakes, allowing me to get things done faster."  I just can't
even *relate* to that viewpoint.  It is that of an alien from a
different universe, so has no bearing on my day to day existence.

Regards,
Pat


Article: 147184
Subject: Re: I'd rather switch than fight!
From: Patrick Maupin <pmaupin@gmail.com>
Date: Fri, 16 Apr 2010 14:09:20 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 16, 1:25=A0pm, rickman <gnu...@gmail.com> wrote:

> Hmmm... =A0The date on that article is 04/07/2003 11:28 AM EDT. =A0Seven
> years later I still don't see any sign that VHDL is going away... or
> did I miss something?

True, but you also have to remember in the early 90s that all the
industry pundits thought verilog was dead...

Article: 147185
Subject: Re: I'd rather switch than fight!
From: Bernd Paysan <bernd.paysan@gmx.de>
Date: Sat, 17 Apr 2010 00:37:49 +0200
Links: << >>  << T >>  << A >>
glen herrmannsfeldt wrote:
> If your test bench is good enough then it will catch all static
> timing failures (eventually).  With static timing analysis, there
> are many things that you don't need to check with the test bench.

And then there are some corner cases where neither static timing analysis 
nor digital simulation helps - like signals crossing asynchronous clock 
boundaries (there *will* be a setup or hold violation, but a robust clock 
boundary crossing circuit will work in practice).

Example: We had a counter running on a different clock (actually a VCO, 
where the voltage was an analog input), and to sample it robust in the 
normal digital clock domain, I grey-encoded it.  There will be one bit which 
is either this or that when sampling at a setup or hold violation condition, 
but this is only just one bit, and it's either in the state before the 
increment or after.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself!"
http://www.jwdt.com/~paysan/

Article: 147186
Subject: Re: I'd rather switch than fight!
From: "evilkidder@googlemail.com" <evilkidder@googlemail.com>
Date: Fri, 16 Apr 2010 20:40:55 -0700 (PDT)
Links: << >>  << T >>  << A >>


> For example, with MyHDL you will also have to learn about latch
> inference and how to avoid "unwanted latches". However, just like in
> VHDL/Verilog there is a much better solution for this than using a
> limited HDL: use a clocked process template by default.
>


I don't agree with this.  Why provide such a general framework when
all you really want is the "clocked process" anyway.  VHDL, Verilog
and MyHDL all let you make the same mistake over and over again.

Cheers,
Andy

Article: 147187
Subject: Re: I'd rather switch than fight!
From: Paul <pault.eg@googlemail.com>
Date: Fri, 16 Apr 2010 23:21:14 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 17 Apr, 04:40, "evilkid...@googlemail.com"
<evilkid...@googlemail.com> wrote:
> > For example, with MyHDL you will also have to learn about latch
> > inference and how to avoid "unwanted latches". However, just like in
> > VHDL/Verilog there is a much better solution for this than using a
> > limited HDL: use a clocked process template by default.
>
> I don't agree with this. =A0Why provide such a general framework when
> all you really want is the "clocked process" anyway. =A0VHDL, Verilog
> and MyHDL all let you make the same mistake over and over again.

AFAIK, to avoid latch inference you need a non-sequential language,
and most don't want that.



Article: 147188
Subject: Re: I'd rather switch than fight!
From: Jan Decaluwe <jan@jandecaluwe.com>
Date: Sat, 17 Apr 2010 01:50:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 17, 5:40=A0am, "evilkid...@googlemail.com"
<evilkid...@googlemail.com> wrote:
> > For example, with MyHDL you will also have to learn about latch
> > inference and how to avoid "unwanted latches". However, just like in
> > VHDL/Verilog there is a much better solution for this than using a
> > limited HDL: use a clocked process template by default.
>
> I don't agree with this. =A0Why provide such a general framework when
> all you really want is the "clocked process" anyway. =A0VHDL, Verilog
> and MyHDL all let you make the same mistake over and over again.

The context of the "clocked process" paradigm is synthesizable RTL
code.
For many engineers working on complex projects, writing such code is
only
a fraction of their work. For high-level modeling and verification,
you can
use the power of the language in its full generality.

For powerful HDLs such as VHDL/Verilog/MyHDL, the synthesis coding
constraints are imposed by synthesis technology, not by the language.
It is easy to design a "fully synthesizable" HDL that incorporates
such
constraints in the language definition itself. It just seems that the
market
doesn't want those. I certainly don't. You are of course free to
ignore
that observation.

Jan

P.S not all latches are "unwanted" :-)

Article: 147189
Subject: Re: I'd rather switch than fight!
From: rickman <gnuarm@gmail.com>
Date: Sat, 17 Apr 2010 07:16:08 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 16, 2:45=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> In comp.arch.fpga rickman <gnu...@gmail.com> wrote:
> (snip)
>
> > I was listening to a lecture by a college once who indicated that you
> > don't need to use static timing analysis since you can use a timing
> > based simulation! =A0I queried him on this a bit and he seemed to think
> > that you just needed to have a "good enough" test bench. =A0I was
> > incredulous about this for a long time. =A0Now I realize he was just a
> > moron^H^H^H^H^H^H^H ill informed!
>
> I suppose so, but consider it the other way around.
>
> If your test bench is good enough then it will catch all static
> timing failures (eventually). =A0With static timing analysis, there
> are many things that you don't need to check with the test bench.

I don't follow what you are saying.  This first sentence seems to be
saying that a timing simulation *is* a good place to find timing
problems, or are you talking about real world test benches?  The point
is that static timing is enough to catch all timing failures given
that your timing constraints cover the design properly... and I agree
that is a big given.  Your second sentence seems to be agreeing with
my previous statement.


> Also, you can't do static timing analysis on the implemented logic.
> (That is, given an actual built circuit and a logic analyzer.)

So?


> Now, setup and hold violations are easy to test with static
> analysis, but much harder to check in actual logic. =A0Among others,
> you would want to check all possible clock skew failures, which is
> normally not possible. =A0With the right test bench and logic
> implementation (including programmable delays on each FF clock)
> it might be possible, though.

In twenty years of designing with FPGAs I have never found a clock
skew problem.  I always write my code to allow the clock trees to
deliver the clocks and I believe the tools guaranty that there will
not be a skew problem.  Static timing actually does cover clock skew,
at least the tools I use.

BTW, how do you design a "right test bench"?  Static timing analysis
will at least give you the coverage level although one of my
complaints is that they don't provide any tools for analyzing if your
constraints are correct.  But I have no idea how to verify that my
test bench is testing the timing adequately.

Rick

Article: 147190
Subject: Microblaze and DDR2
From: "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk>
Date: Sat, 17 Apr 2010 09:48:38 -0500
Links: << >>  << T >>  << A >>
I am trying to integrate my own DDR2 controller into a Microblaze
processor. I have created a board support package file with the ports
defined and have added an IOTYPE attribute of XIL_MEMORY_V1. However when I
run the bsb it thinks that I want to use the Xilinx MPMC. Maybe I shouldnt
be adding this attribute, but I need EDK to know that this is a memory
controller so that it will let me change the memory type in the generate
linker script dialog.

Thanks

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

Article: 147191
Subject: Re: I'd rather switch than fight!
From: rickman <gnuarm@gmail.com>
Date: Sat, 17 Apr 2010 07:48:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 17, 2:21=A0am, Paul <pault...@googlemail.com> wrote:
> On 17 Apr, 04:40, "evilkid...@googlemail.com"
>
> <evilkid...@googlemail.com> wrote:
> > > For example, with MyHDL you will also have to learn about latch
> > > inference and how to avoid "unwanted latches". However, just like in
> > > VHDL/Verilog there is a much better solution for this than using a
> > > limited HDL: use a clocked process template by default.
>
> > I don't agree with this. =A0Why provide such a general framework when
> > all you really want is the "clocked process" anyway. =A0VHDL, Verilog
> > and MyHDL all let you make the same mistake over and over again.
>
> AFAIK, to avoid latch inference you need a non-sequential language,
> and most don't want that.

I'm not clear on what either of you are saying.  I don't seem to have
a problem with latch inferrence mainly because I know what causes
inferred latches.  It has nothing to do with sequential or non-
sequential languages.  VHDL has non-sequential capabilities and I can
infer a latch using that.

a <=3D b when (c =3D '1');  -- use "c" as a latch enable

What am I missing?

Rick

Article: 147192
Subject: Re: Changing output pins slew&drive strength without re-run ISE
From: rickman <gnuarm@gmail.com>
Date: Sat, 17 Apr 2010 07:52:55 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 16, 4:32=A0pm, Gabor <ga...@alacron.com> wrote:
> On Apr 16, 3:16=A0pm, Mawa_fugo <cco...@netscape.net> wrote:
>
> > Hi all,
> > Is there anyway to modify bit file just to change I/O slew rate &
> > drive strength without re-run ISE processes ?
>
> > TIA & TGIF
>
> The easiest way is to use the FPGA editor to modify the
> settings (find your IOB in the "components" list and
> then use "editblock"). =A0Then save the file and just
> re-run bitgen.
>
> Regards,
> Gabor

I have done this when I needed a quick and dirty change to a file
rather than to rerun the entire synthesis.  In fact, I needed a series
of variations because I couldn't get Lattice to tell me what the rise
time specs of their parts are.  They just kept saying it depends on
the state of the rest of the universe.  Certainly they could have
picked a state and spec'd the values the same way other logic parts
do.  I just wanted to get a feel for how the rise time varies with the
two output controls, FAST/SLOW and drive current.  Turns out it is not
as you might expect.

Rick

Article: 147193
Subject: Which 32 bit cores support full Linux?
From: rickman <gnuarm@gmail.com>
Date: Sat, 17 Apr 2010 07:58:30 -0700 (PDT)
Links: << >>  << T >>  << A >>
My customer was talking about running PC Linux on a CPU in an FPGA.  I
believe the one big requirement is that there has to be a MMU.  Which
of the three FPGA vendor's cores are available with a Linux supported
MMU?  I cores I know about from vendors are uBlaze, NIOS and LM32.  I
don't think Actel has one, they seem to be using ARM.  Then of course
there are the gazillion open source cores at all levels of functioning
and support, everything from commercial grade to "What, me worry?"

Which of these are practical for a commercial project?

Rick

Article: 147194
Subject: Re: Which 32 bit cores support full Linux?
From: whygee <yg@yg.yg>
Date: Sat, 17 Apr 2010 18:03:56 +0200
Links: << >>  << T >>  << A >>
rickman wrote:
> My customer was talking about running PC Linux on a CPU in an FPGA.  I
> believe the one big requirement is that there has to be a MMU.  Which
> of the three FPGA vendor's cores are available with a Linux supported
> MMU?  I cores I know about from vendors are uBlaze, NIOS and LM32.  I
> don't think Actel has one, they seem to be using ARM.  Then of course
> there are the gazillion open source cores at all levels of functioning
> and support, everything from commercial grade to "What, me worry?"
> 
> Which of these are practical for a commercial project?

AFAIK, MICO32 seems to work (Seb bourdeauduc could confirm)
but he has switched to another Xilinx-hosted core clone
that is a bit faster for his taste (IIRC), still with Linux.

OTOH, it's not clear : does you client want a PC or Linux ?
because there are (quite) cheap embedded x86 modules around.
I use to play with ETX and PC104, there are new and even smaller
full-featured modules from several manufacturers (like Qseven
form factor, ask me so I send you pictures of the real stuff)

don't waste a FPGA and your time for Linux.
Use existing standard plugable modules...

> Rick
yg

-- 
http://ygdes.com / http://yasep.org

Article: 147195
Subject: Re: Which 32 bit cores support full Linux?
From: John McCaskill <jhmccaskill@gmail.com>
Date: Sat, 17 Apr 2010 09:20:49 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 17, 9:58=A0am, rickman <gnu...@gmail.com> wrote:
> My customer was talking about running PC Linux on a CPU in an FPGA. =A0I
> believe the one big requirement is that there has to be a MMU. =A0Which
> of the three FPGA vendor's cores are available with a Linux supported
> MMU? =A0I cores I know about from vendors are uBlaze, NIOS and LM32. =A0I
> don't think Actel has one, they seem to be using ARM. =A0Then of course
> there are the gazillion open source cores at all levels of functioning
> and support, everything from commercial grade to "What, me worry?"
>
> Which of these are practical for a commercial project?
>
> Rick

Hello Rick,

Starting with version 7, the MicroBlaze processor can have an MMU
included.  Prior to that, you could use the uC version of Linux, which
is designed for processors without an MMU.  That support has been
merged into the 2.6.? version of the kernel.

Take a look at http://www.petalogix.com/ for more information about a
supported distribution of Linux for the MicroBlaze.


Regards,

John McCaskill
www.FasterTechnology.com


Article: 147196
Subject: Re: Microblaze and DDR2
From: John McCaskill <jhmccaskill@gmail.com>
Date: Sat, 17 Apr 2010 09:33:18 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 17, 9:48=A0am, "maxascent"
<maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote:
> I am trying to integrate my own DDR2 controller into a Microblaze
> processor. I have created a board support package file with the ports
> defined and have added an IOTYPE attribute of XIL_MEMORY_V1. However when=
 I
> run the bsb it thinks that I want to use the Xilinx MPMC. Maybe I shouldn=
t
> be adding this attribute, but I need EDK to know that this is a memory
> controller so that it will let me change the memory type in the generate
> linker script dialog.
>
> Thanks
>
> Jon =A0 =A0 =A0 =A0
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com

You do not need to specify the IOTYPE as XIL_MEMORY_V1. I set it to
something else in our XBD file.

In the MPD file for your memory controller, you want to add:

OPTION IP_GROUP =3D  Memory Controller

See psf_rm.pdf in the doc directory of the EDK install for more
information on its syntax.

Regards,

John McCaskill
www.FasterTechnology.com

Article: 147197
Subject: Re: Which 32 bit cores support full Linux?
From: James Salisbury <nntp.dsl.pipex.com>
Date: Sat, 17 Apr 2010 18:30:30 +0100
Links: << >>  << T >>  << A >>
rickman wrote:
> My customer was talking about running PC Linux on a CPU in an FPGA.  I
> believe the one big requirement is that there has to be a MMU.  Which
> of the three FPGA vendor's cores are available with a Linux supported
> MMU?  I cores I know about from vendors are uBlaze, NIOS and LM32.  I
> don't think Actel has one, they seem to be using ARM.  Then of course
> there are the gazillion open source cores at all levels of functioning
> and support, everything from commercial grade to "What, me worry?"
> 
> Which of these are practical for a commercial project?
> 
> Rick
Hi,
Altera do have a demo of linux on Nios on the NEEK kit, it includes a an 
LCD display and other peripherals.


Article: 147198
Subject: Re: Microblaze and DDR2
From: "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk>
Date: Sat, 17 Apr 2010 12:49:51 -0500
Links: << >>  << T >>  << A >>
Thanks John that worked although I had to add ADDR_TYPE = MEMORY to the
C_BASEADDR and C_HIGHADDR parameters.

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

Article: 147199
Subject: Re: I'd rather switch than fight!
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sat, 17 Apr 2010 23:17:35 +0000 (UTC)
Links: << >>  << T >>  << A >>
In comp.arch.fpga rickman <gnuarm@gmail.com> wrote:
(snip on test benches)

>> I suppose so, but consider it the other way around.

>> If your test bench is good enough then it will catch all static
>> timing failures (eventually). ?With static timing analysis, there
>> are many things that you don't need to check with the test bench.
 
> I don't follow what you are saying.  This first sentence seems to be
> saying that a timing simulation *is* a good place to find timing
> problems, or are you talking about real world test benches?  The point
> is that static timing is enough to catch all timing failures given
> that your timing constraints cover the design properly... and I agree
> that is a big given.  Your second sentence seems to be agreeing with
> my previous statement.

Yes, I was describing real world (hardware) test benches.

Depending on how close you are to a setup/hold violation,
it may take a long time for a failure to actually occur.
 
>> Also, you can't do static timing analysis on the implemented logic.
>> (That is, given an actual built circuit and a logic analyzer.)
 
> So?
 
>> Now, setup and hold violations are easy to test with static
>> analysis, but much harder to check in actual logic. ?Among others,
>> you would want to check all possible clock skew failures, which is
>> normally not possible. ?With the right test bench and logic
>> implementation (including programmable delays on each FF clock)
>> it might be possible, though.
 
> In twenty years of designing with FPGAs I have never found a clock
> skew problem.  I always write my code to allow the clock trees to
> deliver the clocks and I believe the tools guaranty that there will
> not be a skew problem.  Static timing actually does cover clock skew,
> at least the tools I use.

Yes, I was trying to cover the case of not using static timing
analysis but only testing actual hardware.  For ASICs, it is 
usually necessary to test the actual chips, though they should
have already passed static timing.  
 
> BTW, how do you design a "right test bench"?  Static timing analysis
> will at least give you the coverage level although one of my
> complaints is that they don't provide any tools for analyzing if your
> constraints are correct.  But I have no idea how to verify that my
> test bench is testing the timing adequately.

If you only have one clock, it isn't so hard.  As you add more,
with different frequencies and/or phases, it gets much harder,
I agree.  It would be nice to get as much help as possible
from the tools.

-- glen



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

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

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

Custom Search