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 155225

Article: 155225
Subject: Re: New soft processor core paper publisher?
From: Eric Wallin <tammie.eric@gmail.com>
Date: Thu, 13 Jun 2013 10:23:56 -0700 (PDT)
Links: << >>  << T >>  << A >>
Thanks for the response John!

> Do you also have an assembler, C++ compiler and debugger for this beast?
> You should have a reference design running on a FPGA board if you want to
> attract a following. Ideally it should also run linux. 

See my response to Nikolaos above.  Full-blown OS support was not the development target.  But it's not a pico-blaze either.  Somewhere in the middle, mainly for FPGA algorithms that can benefit from serialization.

> Why can't you do both. Post the code to opencores.org and then write a
> paper about it and publish.

That's probably the route I'll end up taking.

Article: 155226
Subject: DDR2 Concurrent Auto Precharge
From: Mike Perkins <spam@spam.com>
Date: Thu, 13 Jun 2013 23:12:28 +0100
Links: << >>  << T >>  << A >>
I have come across a VHDL Free Model Foundry mt47h16m16.vhd which gives
me some errors.

Has anyone else used this model?  If so has anyone had issues with twr
timing errors?  Am I right in assuming that this model doesn't feature
Concurrent Auto Precharge?

Is DDR2 like SDR SDRAMs where some devices can cope with concurrent
auto-precharge and others not?  Where if the datasheet doesn't mention
it then it's an unsupported feature?

-- 
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

Article: 155227
Subject: Re: New soft processor core paper publisher?
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 14 Jun 2013 01:44:03 +0100 (BST)
Links: << >>  << T >>  << A >>
Eric Wallin <tammie.eric@gmail.com> wrote:
> Thanks for the response John!
> 
> > Do you also have an assembler, C++ compiler and debugger for this beast?
> > You should have a reference design running on a FPGA board if you want to
> > attract a following. Ideally it should also run linux. 
> 
> See my response to Nikolaos above.  Full-blown OS support was not the
> development target.  But it's not a pico-blaze either.  Somewhere in the
> middle, mainly for FPGA algorithms that can benefit from serialization.

Benchmarks.  Tell us why we should use your processor.  How does it win
compared with the alternatives?

How easy is it to program?  An assembler or a C compiler are really
necessary to make something usable - LLVM may come in handy as a C compiler
toolkit, I'm not sure what's an equivalent assembler toolkit.

Actually synthesise the thing.  It's hard to take seriously something that's
never actually been tested for real, especially if it makes assumptions like
having gigabytes of single-cycle-latency memory.  Debug it and make sure it
works in real hardware.

> > Why can't you do both. Post the code to opencores.org and then write a
> > paper about it and publish.

If you put it on opencores, document document document.  There are tons of
half-baked projects with lame or nonexistent documentation, that kind of
half work on the author's dev system but fall over in real life for one
reason or another.  

Is it vendor-independent, or does it use Xilinx/Altera/etc special stuff? 
If so, how easily can that be replaced with an alternative vendor?

Regression tests and test suites.  How do we know it's working?  Can we work
on the code and make sure we don't break anything?  What does 'working' mean
in the first place?


If you're trying to make an argument in computer architecture you can get
away without some of this stuff (a research prototype can have rough edges
because it's only to prove a point, as long as you tell us what they are). 
Generally you need to tell a convincing story, and either the story is that
XYZ is a useful approach to take (so we can throw away the prototype and
build something better) or XYZ is a component people should use (when it
becomes more convincing if there's more support)

Some lists of well-known conferences:
http://sites.google.com/site/calasweb/fpga-conferences-and-workshops
http://tcfpga.org/conferences.html

Good luck :)

Theo

Article: 155228
Subject: Re: New soft processor core paper publisher?
From: Eric Wallin <tammie.eric@gmail.com>
Date: Fri, 14 Jun 2013 08:43:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
Thanks for your response Theo!

On Thursday, June 13, 2013 8:44:03 PM UTC-4, Theo Markettos wrote:

> Benchmarks.  Tell us why we should use your processor.  How does it win
> compared with the alternatives?

Good point.  So far I've coded a verification boot code gauntlet that it ha=
s passed, as well as restoring division and log2.  If I had more code to pu=
sh through it I could statistically tailor the instruction set (size the im=
mediates, etc.) but I don't.  I may at some point but I may not either.  Th=
is is mainly for me, to help me to implement various projects that require =
complex computations in an FPGA (I currently need it for a digital Theremin=
 that is under development), but I want to release it so others may examine=
 and possibly use it or help me make it better, or use some of the ideas in=
 there in their own stuff.

> How easy is it to program?  An assembler or a C compiler are really
> necessary to make something usable - LLVM may come in handy as a C compil=
er
> toolkit, I'm not sure what's an equivalent assembler toolkit.

It's fairly general purpose and I think if you read the paper you might (or=
 might not) find it easy to understand and program by hand using verilog in=
itial statements.  My main goals were that it be simple enough to grasp wit=
hout tools, complex and fast enough to do real things, have compact opcodes=
 so BRAM isn't wasted, etc.  A compiler, OS, etc. are overkill and definite=
ly not the intended target.

There is a middle ground between trivial and full-blown processors (particu=
larly for FPGA logical use).  Of all the commercial offerings in this range=
 that I'm aware of, my processor is probably most similar to the Parallax P=
ropeller, which is almost certainly pipeline threaded (though they don't te=
ll you that in the documentation).  The Propeller and has a video generator=
; character, sine, and log tables; and other stuff mine doesn't.  But mine =
has a simpler, more unified overall concept and programming model.  It is a=
 true middle ground between register and stack machines.

> Actually synthesise the thing.  It's hard to take seriously something tha=
t's
> never actually been tested for real, especially if it makes assumptions l=
ike
> having gigabytes of single-cycle-latency memory.  Debug it and make sure =
it
> works in real hardware.

Not trying to argue from authority, but I've got 10 years of professional H=
DL experience, and have made several processors in the past for my own edif=
ication and had them up and running on Xilinx demo boards.  This one hasn't=
 actually run in the flesh yet, but it has gone through the build process m=
any times and has been pretty thoroughly verified, so I would be amazed if =
there were any issues (famous last words).  But I'll run it on a Cyclone IV=
 board before releasing it.

> If you put it on opencores, document document document.  There are tons o=
f
> half-baked projects with lame or nonexistent documentation, that kind of
> half work on the author's dev system but fall over in real life for one
> reason or another. =20

I know what you mean, I never use any code directly from there.  To be fair=
, most of the code I ran across in industry was fairly poor as well.  Anywa=
y, I've got a really nice document that took me about a month to write, wit=
h lots of drawings, tables, examples, etc. describing the design and my tho=
ughts behind it.  Even if people don't particularly like my processor they =
might be able to get something out of the background info in the paper (FPG=
A multipliers and RAM, LIFO & ALU design, pipelining, register set construc=
tion, etc.).

> Is it vendor-independent, or does it use Xilinx/Altera/etc special stuff?=
=20
> If so, how easily can that be replaced with an alternative vendor?

I was careful to not use vendor specific constructs in the verilog.  The bl=
ock RAM for main memory the the stacks is inferred, as are the ALU signed m=
ultipliers.  I spent a long time on the modular partitioning of the code wi=
th a strong eye towards verification (as I usually do).  The code was devel=
oped in Quartus, and has been compiled many, many times, but I haven't run =
it through XST yet.

> Regression tests and test suites.  How do we know it's working?  Can we w=
ork
> on the code and make sure we don't break anything?  What does 'working' m=
ean
> in the first place?

I'm probably an odd man out, but I don't agree with a lot of "standard" ind=
ustry verification methodology.  Test benches are fine for really complex c=
ode and / or data environments, but there is no substitute for good coding,=
 proper modular partitioning, and thorough hand testing of each module.  I'=
ve seen too many out of control projects with designers throwing things ove=
r various walls, leaving the verification up to the next guy who usually is=
n't familiar enough with it to really bang on the sensitive parts.  And I k=
ind of hate modelsim.

Anyone that codes should spend a lot of time verifying - I do, and for the =
most part really enjoy it.  The industry has turned this essential activity=
 into something most people loathe, so it just doesn't happen unless people=
 get pushed into doing it.  And even then it usually doesn't get done very =
thoroughly.  Co-developing in environments like that is a nightmare.

> Some lists of well-known conferences:
> http://sites.google.com/site/calasweb/fpga-conferences-and-workshops
> http://tcfpga.org/conferences.html

Thanks, I'll check them out!


Article: 155229
Subject: Re: New soft processor core paper publisher?
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 14 Jun 2013 22:29:15 +0100 (BST)
Links: << >>  << T >>  << A >>
Eric Wallin <tammie.eric@gmail.com> wrote:
> Thanks for your response Theo!
> 
> On Thursday, June 13, 2013 8:44:03 PM UTC-4, Theo Markettos wrote:
> 
> > Benchmarks.  Tell us why we should use your processor.  How does it win
> > compared with the alternatives?
> 
> Good point.  So far I've coded a verification boot code gauntlet that it
> has passed, as well as restoring division and log2.  If I had more code to
> push through it I could statistically tailor the instruction set (size the
> immediates, etc.) but I don't.  I may at some point but I may not either. 
> This is mainly for me, to help me to implement various projects that
> require complex computations in an FPGA (I currently need it for a digital
> Theremin that is under development), but I want to release it so others
> may examine and possibly use it or help me make it better, or use some of
> the ideas in there in their own stuff.

FWIW 'benchmarks' doesn't necessarily mean running SPECfoo at 2.7 times
quicker than a 4004, but things like 'how many instructions does it take to
write division/FFT/quicksort/whatever' compared with the leading brand.  Or
how many LEs, BRAMs, mW, etc.  Numbers are good (as is publishing the source
so we can reproduce them).

> > How easy is it to program?  An assembler or a C compiler are really
> > necessary to make something usable - LLVM may come in handy as a C compiler
> > toolkit, I'm not sure what's an equivalent assembler toolkit.
> 
> It's fairly general purpose and I think if you read the paper you might
> (or might not) find it easy to understand and program by hand using
> verilog initial statements.  My main goals were that it be simple enough
> to grasp without tools, complex and fast enough to do real things, have
> compact opcodes so BRAM isn't wasted, etc.  A compiler, OS, etc.  are
> overkill and definitely not the intended target.

Fair enough.  If you're making architectural points, you can probably get
away with assembly examples.  A simple assembler is good for developer
sanity, though.  Could probably be knocked up in Python reasonably fast.

> > Actually synthesise the thing.  It's hard to take seriously something that's
> > never actually been tested for real, especially if it makes assumptions like
> > having gigabytes of single-cycle-latency memory.  Debug it and make sure it
> > works in real hardware.
> 
> Not trying to argue from authority, but I've got 10 years of professional
> HDL experience, and have made several processors in the past for my own
> edification and had them up and running on Xilinx demo boards.  This one
> hasn't actually run in the flesh yet, but it has gone through the build
> process many times and has been pretty thoroughly verified, so I would be
> amazed if there were any issues (famous last words).  But I'll run it on a
> Cyclone IV board before releasing it.

I'm just a bit jaded from seeing papers at conferences where somebody wrote
some verilog which they only ran in modelsim, and never had to worry about
limited BRAM, or meeting timing, or multiple clock domains, or...

> > If you put it on opencores, document document document.  There are tons of
> > half-baked projects with lame or nonexistent documentation, that kind of
> > half work on the author's dev system but fall over in real life for one
> > reason or another.  
> 
> I know what you mean, I never use any code directly from there.  To be
> fair, most of the code I ran across in industry was fairly poor as well. 
> Anyway, I've got a really nice document that took me about a month to
> write, with lots of drawings, tables, examples, etc.  describing the
> design and my thoughts behind it.  Even if people don't particularly like
> my processor they might be able to get something out of the background
> info in the paper (FPGA multipliers and RAM, LIFO & ALU design,
> pipelining, register set construction, etc.).

This is good.  Just a thought - could you angle it as 'how to do processor
design' using your processor as a case study?  That makes it more of a
useful tutorial than 'buy our brand, it's great'...

> I'm probably an odd man out, but I don't agree with a lot of "standard"
> industry verification methodology.  Test benches are fine for really
> complex code and / or data environments, but there is no substitute for
> good coding, proper modular partitioning, and thorough hand testing of
> each module.  I've seen too many out of control projects with designers
> throwing things over various walls, leaving the verification up to the
> next guy who usually isn't familiar enough with it to really bang on the
> sensitive parts.  And I kind of hate modelsim.

That's not exactly what I meant... let's say you rearrange the pipelining on
your CPU.  It turns out you introduce some obscure bug that causes branches to
jump to the wrong place if there's a multiply 3 instructions back from the
branch.  How would you know if you did this, and make sure it didn't happen
again?  Hand testing modules won't catch that.

It's worse if there's an OS involved, of course.  But it can be easy to
introduce stupid bugs when you're refactoring something, and waste a lot of
time tracking them down.

We use Bluespec so avoid modelsim ;-)
(with Jenkins so we run the test suite for every commit.  A bit overkill for
your needs, perhaps)

> Anyone that codes should spend a lot of time verifying - I do, and for the
> most part really enjoy it.  The industry has turned this essential
> activity into something most people loathe, so it just doesn't happen
> unless people get pushed into doing it.  And even then it usually doesn't
> get done very thoroughly.  Co-developing in environments like that is a
> nightmare.

I admit the tools don't always make it easy...

Theo

Article: 155230
Subject: Re: New soft processor core paper publisher?
From: Eric Wallin <tammie.eric@gmail.com>
Date: Fri, 14 Jun 2013 15:49:31 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Friday, June 14, 2013 5:29:15 PM UTC-4, Theo Markettos wrote:
=20
> FWIW 'benchmarks' doesn't necessarily mean running SPECfoo at 2.7 times
> quicker than a 4004, but things like 'how many instructions does it take =
to
> write division/FFT/quicksort/whatever' compared with the leading brand.  =
Or
> how many LEs, BRAMs, mW, etc.  Numbers are good (as is publishing the sou=
rce
> so we can reproduce them).

I have FPGA resource numbers for the Cyclone III target in the paper.  Brie=
fly, it consumes ~1800 LEs, 4 18x18 multipliers, 4 BRAMs for the stacks, pl=
us whatever the main memory needs.  This is roughly 1/3 of the smallest Cyc=
lone III part.  I have a restoring division example in the paper that gives=
 197 / 293 cycles best / worst case (a thread cycle is 8 200MHz clocks, but=
 there are 8 threads running at this speed so aggregate throughput is poten=
tially 200 MIPs if all threads are busy doing something). =20

I've seen lots of papers that claim speed numbers but don't give the speed =
grade, or tell you what hoops they jumped through to get those speeds.  Wit=
hout that info the speeds are meaningless.

> Fair enough.  If you're making architectural points, you can probably get
> away with assembly examples.  A simple assembler is good for developer
> sanity, though.  Could probably be knocked up in Python reasonably fast.

That's certainly possible.  At this point I'm writing code for it directly =
in verilog using an initial statement text file that gets included in the m=
ain memory.  Several define statements make this clearer and actually fairl=
y easy.  But uploading code to a boot loader would require something like a=
n assembler.  I'm really trying to stay away from the need for toolsets.

> This is good.  Just a thought - could you angle it as 'how to do processo=
r
> design' using your processor as a case study?  That makes it more of a
> useful tutorial than 'buy our brand, it's great'...

The paper is kind of that, background and general how to, but my processor =
doesn't have caches, branch prediction, pipeline hazards, TLBs, etc. so peo=
ple wanting to know how to do that stuff will come up totally empty.

> That's not exactly what I meant... let's say you rearrange the pipelining=
 on
> your CPU.  It turns out you introduce some obscure bug that causes branch=
es to
> jump to the wrong place if there's a multiply 3 instructions back from th=
e
> branch.  How would you know if you did this, and make sure it didn't happ=
en
> again?  Hand testing modules won't catch that.

It's correct by construction! ;-)  Seriously though, there are no hazards t=
o speak of and very little internal state, so branches pretty much either w=
ork or they don't. Once basic functionality was confirmed in simulation, I =
used processor code to check the processor itself e.g. I wrote some code th=
at checks all branches against all possible branch conditions.  Each test i=
ncrements a count if it passes or decrements if it fails.  The final passin=
g number can only be reached if all tests pass.  I've got simple code like =
this to test all of the opcodes.  This exercise can help give an early feel=
 for the completeness of the instruction set as well.  Verifying something =
like the Pentium must be one agonizingly painful mountain to climb.  Verify=
ing each silicon copy must be a bear as well.

Article: 155231
Subject: Re: New soft processor core paper publisher?
From: Eric Wallin <tammie.eric@gmail.com>
Date: Sat, 15 Jun 2013 12:45:48 -0700 (PDT)
Links: << >>  << T >>  << A >>
So is there anything like the old Byte magazine (or a web equivalent) where enthusiasts and other non-academic, non-industry types can publish articles on computers / computing hardware?

Article: 155232
Subject: Re: New soft processor core paper publisher?
From: rickman <gnuarm@gmail.com>
Date: Sat, 15 Jun 2013 20:40:27 -0400
Links: << >>  << T >>  << A >>
On 6/13/2013 1:07 PM, Eric Wallin wrote:
> Thank you for your reply Nikolaos!
>
>> This reads like a "fourstack" architecture on steroids. It seems
>> good!
>
> "A Four Stack Processor" by Bernd Paysan?  I ran across that paper several years ago (thanks!).  Very interesting, but with multiple ALUs, access to data below the LIFO tops, TLBs, security, etc. it is much more complex than my processor.  It looks like a real bear to program and manage at the lowest level.
>
>> How do you compare with more classic RISC-like soft-cores like
>> MicroBlaze, Nios-II, LEON, etc?
>
> The target audience for my processor is an FPGA developer who needs to implement complex functionality that tolerates latency but requires deterministic timing.  Hand coding with no toolchain (verilog initial statement boot code).  Simple enough to keep the processor model and current state in one's head (with room to spare).  Small enough to fit in the smallest of FPGAs (with room to spare).  Not meant at all to run a full-blown OS, but not a trivial processor.

That the ground I have been plowing off and on for the last 10 years.


>> There is also a classic book on stack-based computers, you really need
>> to go through this and reference it in your publication.
>
> "Stack Computers: The New Wave" by Philip J. Koopman, Jr.?  Also ran across that many years ago (thanks!).  The main thrust of it seems to be the advocating of single data stack, single return stack, zero operand machines, which I feel (nothing personal) are crap.  Easy to design and implement (I've made several while under the spell) but impossible to program in an efficient manner (gobs of real time wasted on stack thrash, the minimization of which leads directly to unreadable procedural coding practices, which leads to catastrophic stack faults).

I assume that you do understand that the point of MISC is that the 
implementation can be minimized so that the instructions run faster.  In 
theory this makes up for the extra instructions needed to manipulate the 
stack on occasion.  But I understand your interest in minimizing the 
inconvenience of stack ops.  I spent a little time looking at 
alternatives and am currently looking at a stack CPU design that allows 
offsets into the stack to get around the extra stack ops.  I'm not sure 
how this compares to your ideas.  It is still a dual stack design as I 
have an interest in keeping the size of the implementation at a minimum. 
  1800 LEs won't even fit on the FPGAs I am targeting.


> My processor incorporates what I believe are a couple of new innovations (but who ever really knows?) that I'd like to get out there if possible.  And I wouldn' mind a bit of personal recognition if only for my efforts.

I would like to hear about your innovations.  As you seem to understand, 
it is hard to be truly innovative finding new ideas that others have not 
uncovered.  But I think you are certainly in an area that is not 
thoroughly explored.


> IEEE is probably out.  I fundamentally disagree with the hoarding of tecnical papers behind a greedy paywall.

I won't argue with that.  Even when I was an IEEE member, I never found 
a document I didn't have to pay for.

When can we expect to see your paper?

-- 

Rick

Article: 155233
Subject: Re: New soft processor core paper publisher?
From: Eric Wallin <tammie.eric@gmail.com>
Date: Sat, 15 Jun 2013 19:17:24 -0700 (PDT)
Links: << >>  << T >>  << A >>
Thanks for your response rickman!

On Saturday, June 15, 2013 8:40:27 PM UTC-4, rickman wrote:
> That the ground I have been plowing off and on for the last 10 years.

Ooo, same here, and my condolences.  I caught a break a couple of months ag=
o and have been beavering away on it ever since, and I finally have somethi=
ng that doesn't cause me to vomit when I code for it.  Multiple indexed sim=
ple stacks with explicit pointer control makes everything a lot easier than=
 a bog standard stack machine.  I think the auto-consumption of literally e=
verything, particularly the data, indexes, and pointers you dearly want to =
use again is at the bottom of all the crazy people just accept with stack m=
achines.  This mechanism works great for manual data entry on HP calculator=
s, but not so much for stack machines IMHO.  Auto consumption also pretty m=
uch rules out conditional execution of single instructions.

> I assume that you do understand that the point of MISC is that the=20
> implementation can be minimized so that the instructions run faster.  In=
=20
> theory this makes up for the extra instructions needed to manipulate the=
=20
> stack on occasion.  But I understand your interest in minimizing the=20
> inconvenience of stack ops.  I spent a little time looking at=20
> alternatives and am currently looking at a stack CPU design that allows=
=20
> offsets into the stack to get around the extra stack ops.  I'm not sure=
=20
> how this compares to your ideas.  It is still a dual stack design as I=20
> have an interest in keeping the size of the implementation at a minimum.=
=20

MISC is interesting, but you have to consider that all ops, including simpl=
e stack manipulations, will generally consume as much real time as a multip=
ly, which suddenly makes all of those confusing stack gymnastics you have t=
o perform to dig out your loop index or whatever from underneath your read/=
write pointer from underneath your data and such overly burdensome.

Indexes into a moving stack - that way lies insanity.  Ever hit the roll do=
wn button on an HP calculator and get instantly flummoxed?  Maybe a compile=
r can keep track of that kind of stuff, but my weak brain isn't up to the t=
ask.

Altera BRAM doesn't go as wide as Xilinx with true dual port.  When I was w=
orking in Xilinx I was able to use a single BRAM for both the data and retu=
rn stacks (16 bit data).

>   1800 LEs won't even fit on the FPGAs I am targeting.

I'm not sure anything less than the smallest Cyclone 2 is really worth deve=
loping in.  A lot of the stuff below that is often more expensive due to th=
e built-in configuration memory and such.  There are quite inexpensive Cycl=
one dev boards on eBay from China.

> I would like to hear about your innovations.  As you seem to understand,=
=20
> it is hard to be truly innovative finding new ideas that others have not=
=20
> uncovered.  But I think you are certainly in an area that is not=20
> thoroughly explored.

I haven't seen anything exactly like it, certainly not the way the stacks a=
re implemented.  And I deal with extended arithmetic results in an unusual =
way.  In terms of scheduling and pipelining, the Parallax Propeller is prob=
ably the closest in architecture (you can infer from the specs and operatio=
nal model what they don't explicitly tell you in the datasheet).

> I won't argue with that.  Even when I was an IEEE member, I never found=
=20
> a document I didn't have to pay for.

I was a member too right out of grad school.  But, like Janet Jackson sang:=
 "What have they done for me lately?"

> When can we expect to see your paper?

It's all but done, just picking around the edges at this point.  As soon as=
 the code is verified to my satisfaction I'll release both and post here.

Article: 155234
Subject: Re: DDR2 Concurrent Auto Precharge
From: rickman <gnuarm@gmail.com>
Date: Sat, 15 Jun 2013 23:24:04 -0400
Links: << >>  << T >>  << A >>
On 6/13/2013 6:12 PM, Mike Perkins wrote:
> I have come across a VHDL Free Model Foundry mt47h16m16.vhd which gives
> me some errors.
>
> Has anyone else used this model? If so has anyone had issues with twr
> timing errors? Am I right in assuming that this model doesn't feature
> Concurrent Auto Precharge?
>
> Is DDR2 like SDR SDRAMs where some devices can cope with concurrent
> auto-precharge and others not? Where if the datasheet doesn't mention
> it then it's an unsupported feature?

I haven't worked with DDR2, but I have worked with SDR SDRAM.  I don't 
recall the specific mode you mention, but I'm pretty sure if a given 
device data sheet does not mention any given feature, it isn't in the 
part.

I believe these things are standardized or at least a minimum set of 
features should be standardized.  Using a vendor unique feature means 
you are locked into that vendor.  On the other hand, I believe there is 
a way to read the specifics of the brand and model of RAM you are using 
in a standard way.  So you should be able to query the device to see if 
it supports the feature you want to use.

What does the data sheet for your part say about status and 
configuration settings?

-- 

Rick

Article: 155235
Subject: Re: New soft processor core paper publisher?
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Sun, 16 Jun 2013 10:23:01 +0100
Links: << >>  << T >>  << A >>
Eric Wallin wrote:

> Indexes into a moving stack - that way lies insanity.  Ever hit the roll down button on an HP calculator and get instantly flummoxed?  Maybe a compiler can keep track of that kind of stuff, but my weak brain isn't up to the task.

Have a look at comp.arch, in particular the current discussion about the "belt" in the Mill processor. Start by watching the video.

The Mill is a radical architecture that offers far greater instruction level parallelism than existing processors, partly by having no general purpose registers.

The Mill is irrelevant to FPGA processors; it is aimed at beating x86 machines.


Article: 155236
Subject: Re: New soft processor core paper publisher?
From: Eric Wallin <tammie.eric@gmail.com>
Date: Sun, 16 Jun 2013 06:58:24 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sunday, June 16, 2013 5:23:01 AM UTC-4, Tom Gardner wrote:

> The Mill is irrelevant to FPGA processors...

The Mill looks vaguely interesting (if you're into billion transistor processors) but as you indicated I'm not sure how it is relevant to this thread?

Article: 155237
Subject: Re: New soft processor core paper publisher?
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Sun, 16 Jun 2013 18:16:42 +0100
Links: << >>  << T >>  << A >>
Eric Wallin wrote:
> On Sunday, June 16, 2013 5:23:01 AM UTC-4, Tom Gardner wrote:
>
>> The Mill is irrelevant to FPGA processors...
>
> The Mill looks vaguely interesting (if you're into billion transistor processors) but as you indicated I'm not sure how it is relevant to this thread?

You wrote "Indexes into a moving stack - that way lies insanity."
The Mill's belt is effectively exactly that, and they appear not to have gone insane.


Article: 155238
Subject: Re: DDR2 Concurrent Auto Precharge
From: Mike Perkins <spam@spam.com>
Date: Sun, 16 Jun 2013 22:40:54 +0100
Links: << >>  << T >>  << A >>
On 16/06/2013 04:24, rickman wrote:
> On 6/13/2013 6:12 PM, Mike Perkins wrote:
>> I have come across a VHDL Free Model Foundry mt47h16m16.vhd which
>> gives me some errors.
>>
>> Has anyone else used this model? If so has anyone had issues with
>> twr timing errors? Am I right in assuming that this model doesn't
>> feature Concurrent Auto Precharge?
>>
>> Is DDR2 like SDR SDRAMs where some devices can cope with
>> concurrent auto-precharge and others not? Where if the datasheet
>> doesn't mention it then it's an unsupported feature?
>
> I haven't worked with DDR2, but I have worked with SDR SDRAM.  I
> don't recall the specific mode you mention, but I'm pretty sure if a
> given device data sheet does not mention any given feature, it isn't
> in the part.

I know Micron SDR devices feature concurrent auto-precharge, and another
that didn't, or should I say I had a sample where it didn't work.

> I believe these things are standardized or at least a minimum set of
>  features should be standardized.  Using a vendor unique feature
> means you are locked into that vendor.  On the other hand, I believe
> there is a way to read the specifics of the brand and model of RAM
> you are using in a standard way.  So you should be able to query the
> device to see if it supports the feature you want to use.

I would have thought that in the passage of time this feature would be
an industry standard.  Hence my uncertainly!

> What does the data sheet for your part say about status and
> configuration settings?
>

It's not a configuration issue, the part either support concurrent
auto-precharge or it doesn't.

The part is a Winbond W9725G6KB and I'm beginning to assume that if the
datasheet doesn't mention it then it's not a feature I can reply upon.
However the absence of any restriction of the time between two
auto-precharge instructions on different banks does tends to suggest
that concurrent auto-precharge is inherently possible.

I'm now using a Micron verilog model which is not only unencrypted but
almost holds your hand through the initialisation procedures, and tells
you what data has been written to which row and column!  Superb!  Being
unencrypted means I can also shorten the 200us period where the clock
must be stable for faster simulation!

-- 
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

Article: 155239
Subject: Re: New soft processor core paper publisher?
From: Eric Wallin <tammie.eric@gmail.com>
Date: Sun, 16 Jun 2013 17:32:56 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sunday, June 16, 2013 1:16:42 PM UTC-4, Tom Gardner wrote:

> You wrote "Indexes into a moving stack - that way lies insanity."
> The Mill's belt is effectively exactly that, and they appear not to have gone insane.

I bet they would if they tried to hand code it in assembly! ;-)

The first video comment is priceless: "Gandalf?"


Article: 155240
Subject: Re: New soft processor core paper publisher?
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Mon, 17 Jun 2013 11:26:49 +0100
Links: << >>  << T >>  << A >>
Eric Wallin wrote:
> On Sunday, June 16, 2013 1:16:42 PM UTC-4, Tom Gardner wrote:
>
>> You wrote "Indexes into a moving stack - that way lies insanity."
>> The Mill's belt is effectively exactly that, and they appear not to have gone insane.
>
> I bet they would if they tried to hand code it in assembly! ;-)

It *is* considerably easier than hand-coding Itanium. With that
you change *any* aspect of the microarchitecture and you go back
to the beginning. How do I know? I asked someone that was doing
it to assess its performance, and decided to Run Away from
anything to do with the Itanium.


> The first video comment is priceless: "Gandalf?"

How shallow :)



Article: 155241
Subject: Re: DDR2 Concurrent Auto Precharge
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Mon, 17 Jun 2013 09:07:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
I've used the Micron Verilog models a couple of times.  They're written in =
oldschool Verilog, but they're pretty good.  I have to go in and change som=
e parameters to make them work with my parts, and then they are very detail=
ed.  I also put in the Modelsim metacomment to make the RAM array sparse wh=
ich speeds up the sim a lot.

Article: 155242
Subject: Re: Modelsim ought to be cheaper
From: Sanjay Parekh <parekhsanjayh@gmail.com>
Date: Mon, 17 Jun 2013 12:08:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Tuesday, April 23, 2013 1:13:42 PM UTC-7, Kevin Neilson wrote:
> Why is Modelsim so expensive?  It is a mature product and yet it segfault=
s on me all the time.  Constantly.  Often, when it ought to give me warning=
s or errors (such as when there is a port width mismatch) it just core dump=
s instead, leaving me to comment out lines one at a time until I figure out=
 why it's crashing.  That's my rant.  It's still pretty decent, but ought t=
o be cheaper if it's going to coredump like freeware.

I use Questa on Windows 7 64 bit on intel based machine for my SystemVerilo=
g designs.  I can tell you that I have never seen a coredump lately.  Nonet=
heless, occasionally, the tool would simply exit with a cryptic code during=
 compile, optimization or elaboration stage.  At which point I have to file=
 a support request.  Sometimes, I would be able to get an idea on the probl=
em - something silly, by turning off the vopt switch at which point I would=
 think why wasn't the tool able to flag this without giving up!

What would be the groups' sentiment if there was a cloud service to use the=
 tool on a timeshare basis?

I can see a win-win scenario for vendors and the developer community.


Article: 155243
Subject: Re: DDR2 Concurrent Auto Precharge
From: rickman <gnuarm@gmail.com>
Date: Mon, 17 Jun 2013 19:55:41 -0400
Links: << >>  << T >>  << A >>
On 6/16/2013 5:40 PM, Mike Perkins wrote:
> On 16/06/2013 04:24, rickman wrote:
>> On 6/13/2013 6:12 PM, Mike Perkins wrote:
>>> I have come across a VHDL Free Model Foundry mt47h16m16.vhd which
>>> gives me some errors.
>>>
>>> Has anyone else used this model? If so has anyone had issues with
>>> twr timing errors? Am I right in assuming that this model doesn't
>>> feature Concurrent Auto Precharge?
>>>
>>> Is DDR2 like SDR SDRAMs where some devices can cope with
>>> concurrent auto-precharge and others not? Where if the datasheet
>>> doesn't mention it then it's an unsupported feature?
>>
>> I haven't worked with DDR2, but I have worked with SDR SDRAM. I
>> don't recall the specific mode you mention, but I'm pretty sure if a
>> given device data sheet does not mention any given feature, it isn't
>> in the part.
>
> I know Micron SDR devices feature concurrent auto-precharge, and another
> that didn't, or should I say I had a sample where it didn't work.
>
>> I believe these things are standardized or at least a minimum set of
>> features should be standardized. Using a vendor unique feature
>> means you are locked into that vendor. On the other hand, I believe
>> there is a way to read the specifics of the brand and model of RAM
>> you are using in a standard way. So you should be able to query the
>> device to see if it supports the feature you want to use.
>
> I would have thought that in the passage of time this feature would be
> an industry standard. Hence my uncertainly!
>
>> What does the data sheet for your part say about status and
>> configuration settings?
>>
>
> It's not a configuration issue, the part either support concurrent
> auto-precharge or it doesn't.

I mean there may be a status something indicating what features are 
supported.  It has been a long time since I read an SDRAM data sheet, 
but I recall something like this in the part I used.  There were 
extended bits of some sort for extended features.


> The part is a Winbond W9725G6KB and I'm beginning to assume that if the
> datasheet doesn't mention it then it's not a feature I can reply upon.
> However the absence of any restriction of the time between two
> auto-precharge instructions on different banks does tends to suggest
> that concurrent auto-precharge is inherently possible.
>
> I'm now using a Micron verilog model which is not only unencrypted but
> almost holds your hand through the initialisation procedures, and tells
> you what data has been written to which row and column! Superb! Being
> unencrypted means I can also shorten the 200us period where the clock
> must be stable for faster simulation!

-- 

Rick

Article: 155244
Subject: Chasing Bugs in the Fog
From: rickman <gnuarm@gmail.com>
Date: Mon, 17 Jun 2013 20:00:01 -0400
Links: << >>  << T >>  << A >>
I have a bug in a test fixture that is FPGA based.  I had thought it was 
in the software which controls it, but after many hours of chasing it 
around I've concluded it must be in the FPGA code.

I didn't think it was in the VHDL because it had been simulated well and 
the nature of the bug is an occasional dropped character on the receive 
side.  Who can't design a UART?  Well, it could be in the handshake with 
the state machine, but still...

So I finally got around to adding some debug signals which I would 
monitor on an analyzer and guess what, the bug is gone!  I *hate* when 
that happens.  I can change the code so the debug signals only appear 
when a control register is set to enable them, but still, I don't like 
this.  I want to know what is causing this DURN THING!

Anyone see this happen to them before?

Oh yeah, someone in another thread (that I can't find, likely because I 
don't recall the group I posted it in) suggested I add synchronizing FFs 
to the serial data in.  Sure enough I had forgotten to do that.  Maybe 
that was the fix...  of course!  It wasn't metastability, I bet it was 
feeding multiple bits of the state machine!  Durn, I never make that 
sort of error.  Thanks to whoever it was that suggested the obvious that 
I had forgotten.

-- 

Rick

Article: 155245
Subject: Re: Chasing Bugs in the Fog
From: Rob Gaddi <rgaddi@technologyhighland.invalid>
Date: Mon, 17 Jun 2013 17:14:58 -0700
Links: << >>  << T >>  << A >>
On Mon, 17 Jun 2013 20:00:01 -0400
rickman <gnuarm@gmail.com> wrote:

> So I finally got around to adding some debug signals which I would 
> monitor on an analyzer and guess what, the bug is gone!  I *hate* when 
> that happens.  I can change the code so the debug signals only appear 
> when a control register is set to enable them, but still, I don't like 
> this.  I want to know what is causing this DURN THING!
> 
> Anyone see this happen to them before?
> 
> Oh yeah, someone in another thread (that I can't find, likely because I 
> don't recall the group I posted it in) suggested I add synchronizing FFs 
> to the serial data in.  Sure enough I had forgotten to do that.  Maybe 
> that was the fix...  of course!  It wasn't metastability, I bet it was 
> feeding multiple bits of the state machine!  Durn, I never make that 
> sort of error.  Thanks to whoever it was that suggested the obvious that 
> I had forgotten.
> 
> -- 
> 
> Rick

Not metastability, a race condition.  Asynchronous external input
headed to multiple clocked elements, each of which it reaches via a
different path with a different delay.

When you added debugging signals you changed the netlist, which changed
the place and route, making unpredictable changes to those delays.  In
this case, it happened to push it into a place where _as far as you
tested_, it seems happy.  But it's still unsafe, because as you change
other parts of the design, the P&R of that section will still change
anyhow, and you start getting my favorite situation, the problem that
comes and goes based on entirely unrelated factors.

The fix you fixed fixes it.  When you resynchronized it on the same
clock as you're running around the rest of the logic, you forced that
path to become timing constrained.  As such, the P&R takes it upon
itself to make sure that the timing of that route is irrelevant with
respect to the clock period, and your problem goes away for good.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

Article: 155246
Subject: Ask about finding maximum and second's maximum number in array is given.
From: phanhuyich <khanhnguyentang@gmail.com>
Date: Mon, 17 Jun 2013 18:19:08 -0700 (PDT)
Links: << >>  << T >>  << A >>
I am starting to study VHDL. Now, I have to do an exercise with the following content:

 I have to define an array of 10 elements ( 8 bit range) ([3,4,2,8,9,0,1,5,7,6] for example). And 10 elements were imported to within 10 clock cycles. The question is find the maximum number and second maximum number in this array after 10 clock cycle.
 Anyone help to show me the method to solve it using VHDL ?

 Thank you.

Article: 155247
Subject: Re: Ask about finding maximum and second's maximum number in array is given.
From: Thomas Stanka <usenet_nospam_valid@stanka-web.de>
Date: Tue, 18 Jun 2013 04:28:22 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 18 Jun., 03:19, phanhuyich <khanhnguyent...@gmail.com> wrote:
> I am starting to study VHDL. Now, I have to do an exercise with the follo=
wing content:
>
> =A0I have to define an array of 10 elements ( 8 bit range) ([3,4,2,8,9,0,=
1,5,7,6] for example). And 10 elements were imported to within 10 clock cyc=
les. The question is find the maximum number and second maximum number in t=
his array after 10 clock cycle.
> =A0Anyone help to show me the method to solve it using VHDL ?

No problem. Just write down your sollution to that problem in "not
VHDL". Then ask what part of the algorithm is hard for you transfer in
VHDL and why so we can help.

HInt it helps to think about the RTL and draw a picture about how the
data flow might be than it is easy to write it down in VHDL.

regards Thomas


Article: 155248
Subject: Re: Chasing Bugs in the Fog
From: "jt_eaton" <84408@embeddedrelated>
Date: Tue, 18 Jun 2013 08:23:56 -0500
Links: << >>  << T >>  << A >>

>So I finally got around to adding some debug signals which I would 
>monitor on an analyzer and guess what, the bug is gone!  I *hate* when 
>that happens.  I can change the code so the debug signals only appear 
>when a control register is set to enable them, but still, I don't like 
>this.  I want to know what is causing this DURN THING!
>
>Anyone see this happen to them before?
>
>-- 
>
>Rick
>

Yes, This is called a "Heisenbug". Usually involves a clock domain
crossing
mistake.


John Eaton
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 155249
Subject: Re: DDR2 Concurrent Auto Precharge
From: Mike Perkins <spam@spam.com>
Date: Tue, 18 Jun 2013 17:00:57 +0100
Links: << >>  << T >>  << A >>
On 18/06/2013 00:55, rickman wrote:
> On 6/16/2013 5:40 PM, Mike Perkins wrote:
>> On 16/06/2013 04:24, rickman wrote:
>>> On 6/13/2013 6:12 PM, Mike Perkins wrote:
>>>> I have come across a VHDL Free Model Foundry mt47h16m16.vhd
>>>> which gives me some errors.
>>>>
>>>> Has anyone else used this model? If so has anyone had issues
>>>> with twr timing errors? Am I right in assuming that this model
>>>> doesn't feature Concurrent Auto Precharge?
>>>>
>>>> Is DDR2 like SDR SDRAMs where some devices can cope with
>>>> concurrent auto-precharge and others not? Where if the
>>>> datasheet doesn't mention it then it's an unsupported feature?
>>>
>>> I haven't worked with DDR2, but I have worked with SDR SDRAM. I
>>> don't recall the specific mode you mention, but I'm pretty sure
>>> if a given device data sheet does not mention any given feature,
>>> it isn't in the part.
>>
>> I know Micron SDR devices feature concurrent auto-precharge, and
>> another that didn't, or should I say I had a sample where it didn't
>> work.
>>
>>> I believe these things are standardized or at least a minimum set
>>> of features should be standardized. Using a vendor unique
>>> feature means you are locked into that vendor. On the other hand,
>>> I believe there is a way to read the specifics of the brand and
>>> model of RAM you are using in a standard way. So you should be
>>> able to query the device to see if it supports the feature you
>>> want to use.
>>
>> I would have thought that in the passage of time this feature would
>> be an industry standard. Hence my uncertainly!
>>
>>> What does the data sheet for your part say about status and
>>> configuration settings?
>>>
>>
>> It's not a configuration issue, the part either support concurrent
>> auto-precharge or it doesn't.
>
> I mean there may be a status something indicating what features are
> supported.  It has been a long time since I read an SDRAM data sheet,
>  but I recall something like this in the part I used.  There were
> extended bits of some sort for extended features.

Sorry, I didn't mean to be disingenuous.  I'm not aware of there being a
status bit and, as I've been told, Concurrent Auto Precharge is not a
JEDEC specified feature.  The only way to finding out, apart from
reading the datasheet of course, is to try and perform an Auto Precharge
on more than bank at once and see if the data is corrupted!


-- 
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk



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