--- In fpga-cpu@yahoogroups.com, John Kent <jekent@...> wrote:
>
> Hi Tommy,
>
> I don't really like using my Visa card on the internet. I'm always
> worried about key loggers. I do run internet security software, but I'm
> still worried about it.

Around here, our exposure to fraudulent transactions is limited to $50.  Beyond
that, the bank eats it (and passes it along...).

I use my Visa at least a couple of dozen times per month for online transactions
and I have been doing it for as long as there have been online suppliers.  I
don't give it a moment's thought.

Richard

Hi Brett,

Yes ... I was thinking of that when I wrote my post.

John.

Brett Wildermoth wrote:
> With the australian dollar so strong right now, it has never been a
> better time to buy from amazon.....
>
> Brett Wildermoth  BEng (ME) MPhil
> Lecturer - Griffith School of Engineering
> Email: B.Wildermoth@...
>
>

--
http://www.johnkent.com.au
http://members.optusnet.com.au/jekent

With the australian dollar so strong right now, it has never been a
better time to buy from amazon.....

Brett Wildermoth  BEng (ME) MPhil
Lecturer - Griffith School of Engineering
Email: B.Wildermoth@...






On 18/10/2009, at 1:42 PM, John Kent wrote:

> Hi Tommy,
>
> I don't really like using my Visa card on the internet. I'm always
> worried about key loggers. I do run internet security software, but
> I'm
> still worried about it.
>
> I can get the book through the RMIT University Bookshop here in
> Melbourne Australia, but I have a local bookshop that supports a
> number
> of community activities that I am involved with, so I prefer to buy
> books through them, even though they are a little more expensive.
> Buying
> books from Amazon, you have to factor in exchange rates and postage,
> which makes them a bit more expensive than the prices listed on the
> web.
>
> The Least Recently Used algorithm is not hard to understand. I just
> could not match up the letters in the acronym although I should have
> thought about it before posting. I have done a paper design on a
> associative cache using LRU some years ago. It used a shift register
> for
> the address and a multiplexer which routed the address back to the
> head
> of the FIFO every time a hit was detected. Cache addresses that fell
> out
> the end of the shift register were written back to SDRAM if they were
> dirty. As I think you mentioned, you needed to maintain a separate RAM
> for each of the cache lines to flag if the cache has been written to.
> Writing a flag to each individual word obviously does not help you
> determine if the cache line is dirty. I also included a unique token
> for
> each address in the associative cache to index the tag (?) cache. The
> token is recycled if the cache entry is written back to memory.
>
> John.
>
> Tommy Thorn wrote:
> > The H&P is considered the "bible" of computer architecture. Amazon
> is your friend.
> >
> >
> > Tommy
> >
> >
>
> --
> http://www.johnkent.com.au
> http://members.optusnet.com.au/jekent
>
>
>



[Non-text portions of this message have been removed]

Hi Tommy,

I don't really like using my Visa card on the internet. I'm always
worried about key loggers. I do run internet security software, but I'm
still worried about it.

I can get the book through the RMIT University Bookshop here in
Melbourne Australia, but I have a local bookshop that supports a number
of community activities that I am involved with, so I prefer to buy
books through them, even though they are a little more expensive. Buying
books from Amazon, you have to factor in exchange rates and postage,
which makes them a bit more expensive than the prices listed on the web.

The Least Recently Used algorithm is not hard to understand. I just
could not match up the letters in the acronym although I should have
thought about it before posting.  I have done a paper design on a
associative cache using LRU some years ago. It used a shift register for
the address and a multiplexer which routed the address back to the head
of the FIFO every time a hit was detected. Cache addresses that fell out
the end of the shift register were written back to SDRAM if they were
dirty. As I think you mentioned, you needed to maintain a separate RAM
for each of the cache lines to flag if the cache has been written to.
Writing a flag to each individual word obviously does not help you
determine if the cache line is dirty. I also included a unique token for
each address in the associative cache to index the tag (?) cache. The
token is recycled if the cache entry is written back to memory.

John.

Tommy Thorn wrote:
> The H&P is considered the "bible" of computer architecture. Amazon is your
friend.
>
>
> Tommy
>
>

--
http://www.johnkent.com.au
http://members.optusnet.com.au/jekent

Norm asked:
   I only asked because of several reviews like:
   "This book has a lot of information, especially with the appendices on CD
and in the back of the book. If you are new to Architecture, I wouldn't
recommend it. Get a simpler book...maybe by the same authors, just the
"prerequisite" for this one."
   Norm

In the past I have also recommended Computer Organization by P&H e.g.
http://www.amazon.com/Computer-Organization-Design-Fourth-Architecture/dp/01
23744938 as a first book in computer architecture, particularly for
self-study.  At least compared to CA:AQA, it offers a more gentle
introduction, e.g. to the details in the design of a pipelined RISC
processor.

Jan.

--- In fpga-cpu@yahoogroups.com, Tommy Thorn <tt1729@...> wrote:
>
> --- On Wed, 10/14/09, normnet2003 <normnet@...> wrote:
> > From: normnet2003 <normnet@...>
> > Tommy Thorn <tt1729@> wrote:
> > > >
> > > > The H&P is considered the "bible" of computer
> > architecture. Amazon is your friend.
> >
> > Is their a prep book for before "Computer Architecture: A
> > Quantitative Approach"?
>
> I don't understand. The book I cited,
http://www.amazon.com/Computer-Architecture-Quantitative-Approach-4th/dp/0123704\
901/ref=dp_ob_image_bk, _is_ "Computer Architecture: A Quantitative Approach".
>
> One of the things that is appreciable about this book is that it's kept
reasonable well up to date, though a lot of material from the 3rd ed was dropped
in the 4th. I have both and look to both for coverage on topics.
>
> A lot of other books have been mentioned in this thread. I'm sure they are
fine too. I also have "classic" text and some that are merely "old", but for
state of the art I haven't found anything better than the above.
>
>
> What happened to the original topic, on DDR SDRAM controllers? So far the only
I've heard of is the one from OpenCores.
>
> Tommy
>
I only asked because of several reviews like:
"This book has a lot of information, especially with the appendices on CD and in
the back of the book. If you are new to Architecture, I wouldn't recommend it.
Get a simpler book...maybe by the same authors, just the "prerequisite" for this
one."

Norm

--- On Wed, 10/14/09, normnet2003 <normnet@...> wrote:
> From: normnet2003 <normnet@...>
> Tommy Thorn <tt1729@> wrote:
> > >
> > > The H&P is considered the "bible" of computer
> architecture. Amazon is your friend.
>
> Is their a prep book for before "Computer Architecture: A
> Quantitative Approach"?

I don't understand. The book I cited,
http://www.amazon.com/Computer-Architecture-Quantitative-Approach-4th/dp/0123704\
901/ref=dp_ob_image_bk, _is_ "Computer Architecture: A Quantitative Approach".

One of the things that is appreciable about this book is that it's kept
reasonable well up to date, though a lot of material from the 3rd ed was dropped
in the 4th. I have both and look to both for coverage on topics.

A lot of other books have been mentioned in this thread. I'm sure they are fine
too. I also have "classic" text and some that are merely "old", but for state of
the art I haven't found anything better than the above.


What happened to the original topic, on DDR SDRAM controllers? So far the only
I've heard of is the one from OpenCores.

Tommy

--- In fpga-cpu@yahoogroups.com, Nigel.Gunton@... wrote:

> Yes, this one is worth tracking down, it's a good introduction. BLUE also
> bears more than a passing resemblance to the Apollo Guidance Computer.
>

I bought a CD on eBay that documents the AGC.  There is at least one project on
the Internet that implements a version of it but it's HUGE (physically).

I have been thinking about implementing a version in an FPGA.  The problem is
what to actually DO with it.  It's not like I have a bunch of retro-rockets out
in the garage.  Still, it would be a good addition to the NASA Space Shuttle
"Liftoff" CD/game.

The control panel is pretty easy.  A few 7 segment displays and a keypad.


> Another introductory text which has some good examples is Carpinelli's
> 'Computer Systems Organization and Architecture' but it's not particularly
> cheap, even second hand. The sections on arithmetic and cache are good
> with RTL descriptions and schematics.

Alibris has copies from $25  I look forward to reading it!

>
> Also secondhand and possibly possibly worth a look is Feldman &
> Retter's 1994 "Computer Architecture, A designer's text based on a generic
> RISC" ($6)

Again, this is something I will enjoy reading.

I really appreciate all of the recommendations for my library but it's clearly
gotten out of hand.  I still have my original "8080 Microcomputer Systems User's
Manual" from 1975.  And everything in between...  Some of the books are
classics, others are just old.  The problem is separating them.

Richard

On Thu, 15 Oct 2009, rtstofer wrote:

>
>
>
8<--snip
>
> For a VERY introductory text, I like Computer Architecture (2d edition)
> by Foster ($3 at Alibris). The book is quite obsolete and talks about
> stuff like drum memory but there is a discussion of a very elementary
> computer (BLUE) that nobody would want to buy today. All of the gate
> level logic is shown and it was a kick to implement in a Spartan 3.
> Thirty years ago I was thinking about buildling it in TTL but the 8080
> came out and I jumped in with the Altair 8800.
>
Yes, this one is worth tracking down, it's a good introduction. BLUE also
bears more than a passing resemblance to the Apollo Guidance Computer.

Another introductory text which has some good examples is Carpinelli's
'Computer Systems Organization and Architecture' but it's not particularly
cheap, even second hand. The sections on arithmetic and cache are good
with RTL descriptions and schematics.

Also secondhand and possibly possibly worth a look is Feldman &
Retter's 1994 "Computer Architecture, A designer's text based on a generic
RISC" ($6)

Nigel G
--
Nigel Gunton,  Senior lecturer,
Department of Design & Engineering,
Bristol Institute of Technology , UWE, Bristol, BS16 1QY
Phone : +44/0 117 32 83630 Fax : +44/0 117 32 83002


This email was independently scanned for viruses by McAfee anti-virus software
and none were found

--- In fpga-cpu@yahoogroups.com, Hellwig Geisse <Hellwig.Geisse@...> wrote:
>
> On Thu, 2009-10-15 at 03:30 +0000, normnet2003 wrote:
>
> > Is their a prep book for before "Computer Architecture: A Quantitative
> > Approach"?
>
> "Computer Organization & Design: The Hardware/Software Interface"
> by the same pair of authors.
>
> Hellwig
>

If you want to do non-restoring division and you can't seem to 'get it' via the
standard texts, there's a nice description in "Introduction To Arithmetic For
Digital Systems Designes" by Waser and Flynn (1982).  They even have a
'microcode' description that makes it pretty easy to implement in VHDL or
Verilog.

I really wanted 2's complement non-restoring division.  I bought a veritable
library of books on computer arithmetic until I finally got the answer (that I
could understand).  Pretty expensive divider...

I buy a lot of used books at www.alibris.com  And the rest at Amazon...

For a VERY introductory text, I like Computer Architecture (2d edition) by
Foster ($3 at Alibris).  The book is quite obsolete and talks about stuff like
drum memory but there is a discussion of a very elementary computer (BLUE) that
nobody would want to buy today.  All of the gate level logic is shown and it was
a kick to implement in a Spartan 3.  Thirty years ago I was thinking about
buildling it in TTL but the 8080 came out and I jumped in with the Altair 8800.

There is a table driven assembler ( http://home.comcast.net/~tasm/ ) which makes
it trivial (maybe a couple of hours work) to implement a full featured
cross-assembler for the processor.

I was thinking about BLUE as a learning exercise and science project for my
grandson.  In the early '60s you could have been king of the hill with a
computer like this.  OK, maybe late '50s.

Even the IBM1130 (released in 1965) was available with just 4k and paper tape. 
The 27 pass Fortran compiler worked just fine (AFAIK).  BLUE has similar
features but a much reduced instruction set.

Richard

On Thu, 2009-10-15 at 03:30 +0000, normnet2003 wrote:

> Is their a prep book for before "Computer Architecture: A Quantitative
> Approach"?

"Computer Organization & Design: The Hardware/Software Interface"
by the same pair of authors.

Hellwig

--- In fpga-cpu@yahoogroups.com, "rtstofer" <rstofer@...> wrote:
>
>
>
> --- In fpga-cpu@yahoogroups.com, Tommy Thorn <tt1729@> wrote:
> >
> > The H&P is considered the "bible" of computer architecture. Amazon is your
friend.
> >
> >
> > Tommy
>
> Ordered last week.  Should be here soon.
>
> Richard
>

Is their a prep book for before "Computer Architecture: A Quantitative
Approach"?

Norm

--- In fpga-cpu@yahoogroups.com, Tommy Thorn <tt1729@...> wrote:
>
> The H&P is considered the "bible" of computer architecture. Amazon is your
friend.
>
>
> Tommy

Ordered last week.  Should be here soon.

Richard

The H&P is considered the "bible" of computer architecture. Amazon is your
friend.


Tommy


--- On Fri, 10/9/09, John Kent <jekent@...> wrote:

> From: John Kent <jekent@...>
> Subject: Re: [fpga-cpu] Re: Using DDR RAM
> To: fpga-cpu@yahoogroups.com
> Date: Friday, October 9, 2009, 10:58 PM
>
>
> Tommy Thorn wrote:
> > --- On Thu, 10/8/09, e2kcpu <e2kcpu@...>
> wrote:
> >
> > That's technically accurate, but probably not
> meaningful without sufficient background.
> >
> > John, I don't think I have enough time to do the topic
> justice. I strongly encourage you get the a copy of
> Patterson & Hennessey:
http://www.amazon.com/Computer-Architecture-Quantitative-Approach-4th/dp/0123704\
901/ref=dp_ob_image_bk
> > Seriously, this should be considered required reading
> for anyone on this list.
> >
> > Of course, my replacement is only /pseudo-/random as I
> use the low two bits of a 10-bit LFSR, not all that random
> actually.
> >
> > Cheers
> > Tommy
> >   
> I have seen that book, although I think my local bookshop
> might have had
> difficulty in getting it in. I did buy "The Art of
> Multiprocessor
> Programming"  by Herlihy and Shavit, although that
> covers more
> concurrency and interlocks than caching.
>
> John.
>
> --
> http://www.johnkent.com.au
> http://members.optusnet.com.au/jekent
>
>
>
> ------------------------------------
>
> To post a message, send it to: fpga-cpu@yahoogroups.com
> To unsubscribe, send a blank message to:
fpga-cpu-unsubscribe@...!
> Groups Links
>
>
>     mailto:fpga-cpu-fullfeatured@yahoogroups.com
>
>
>

Tommy Thorn wrote:
> --- On Thu, 10/8/09, e2kcpu <e2kcpu@...> wrote:
>
> That's technically accurate, but probably not meaningful without sufficient
background.
>
> John, I don't think I have enough time to do the topic justice. I strongly
encourage you get the a copy of Patterson & Hennessey:
http://www.amazon.com/Computer-Architecture-Quantitative-Approach-4th/dp/0123704\
901/ref=dp_ob_image_bk
> Seriously, this should be considered required reading for anyone on this list.
>
> Of course, my replacement is only /pseudo-/random as I use the low two bits of
a 10-bit LFSR, not all that random actually.
>
> Cheers
> Tommy
>
I have seen that book, although I think my local bookshop might have had
difficulty in getting it in. I did buy "The Art of Multiprocessor
Programming"  by Herlihy and Shavit, although that covers more
concurrency and interlocks than caching.

John.

--
http://www.johnkent.com.au
http://members.optusnet.com.au/jekent

Tommy Thorn wrote:
> --- On Thu, 10/8/09, e2kcpu <e2kcpu@...> wrote:
>
>
>> From: e2kcpu <e2kcpu@...>
>>
>>
>> What about :
>> http://en.wikipedia.org/wiki/Cache_algorithms
>>
>
> That's technically accurate, but probably not meaningful without sufficient
background.
>
> John, I don't think I have enough time to do the topic justice. I strongly
encourage you get the a copy of Patterson & Hennessey:
http://www.amazon.com/Computer-Architecture-Quantitative-Approach-4th/dp/0123704\
901/ref=dp_ob_image_bk
> Seriously, this should be considered required reading for anyone on this list.
>
> Of course, my replacement is only /pseudo-/random as I use the low two bits of
a 10-bit LFSR, not all that random actually.
>
> Cheers
> Tommy
>
Thanks Tommy,

My delay in responding is because I am working on a conference paper
that is over due, although developing effective caching techniques is an
important aspect of my research.

John.

--
http://www.johnkent.com.au
http://members.optusnet.com.au/jekent

e2kcpu wrote:
> --- In fpga-cpu@yahoogroups.com, John Kent <jekent@...> wrote:
>
>> Can you possible explain random replacement a little better and excuse
>> my ignorance, but what does LRU stand for ?
>>
>
> What about :
> http://en.wikipedia.org/wiki/Cache_algorithms
>
>
Yep, Least Recently Used ...
Should have thought of that.

Thanks

John.

--
http://www.johnkent.com.au
http://members.optusnet.com.au/jekent

--- On Thu, 10/8/09, e2kcpu <e2kcpu@...> wrote:

> From: e2kcpu <e2kcpu@...>
> Subject: [fpga-cpu] Re: Using DDR RAM
> To: fpga-cpu@yahoogroups.com
> Date: Thursday, October 8, 2009, 5:45 AM
> --- In fpga-cpu@yahoogroups.com,
> John Kent <jekent@...> wrote:
> > Can you possible explain random replacement a little
> better and excuse
> > my ignorance, but what does LRU stand for ?
>
> What about :
> http://en.wikipedia.org/wiki/Cache_algorithms

That's technically accurate, but probably not meaningful without sufficient
background.

John, I don't think I have enough time to do the topic justice. I strongly
encourage you get the a copy of Patterson & Hennessey:
http://www.amazon.com/Computer-Architecture-Quantitative-Approach-4th/dp/0123704\
901/ref=dp_ob_image_bk
Seriously, this should be considered required reading for anyone on this list.

Of course, my replacement is only /pseudo-/random as I use the low two bits of a
10-bit LFSR, not all that random actually.

Cheers
Tommy

--- In fpga-cpu@yahoogroups.com, John Kent <jekent@...> wrote:
> Can you possible explain random replacement a little better and excuse
> my ignorance, but what does LRU stand for ?

What about :
http://en.wikipedia.org/wiki/Cache_algorithms

Tommy Thorn wrote:
> Thanks for the pitch. I've been very busy since, but there are a few
> changes in the "pipeline": SDRAM support for DE2-70 and SSRAM support
> for ML-401.
>
> There is definitely a lack of DDR controllers. This is truly a Frequently
> Asked Question. A while back there was a posting of a port of an Open Cores
DDR controller to one of the Digilent Spartan 3 boards. I got it
> running on the Spartan 3S1600 board.
>
> All modern dynamic RAM are designed for caches. The data cache and instruction
cache in YARI should be fairly straight forward to follow, but they also aren't
particularly sophisticated. In particular they:
> - Use random replacement. There is a request for LRU replacement for real-
>   time reasons.
> - Are write through caches. Implementing a write-back cache requires an
>   additional bitmap for dirty lines. (Also the line replacement policy
>   design space grows more interesting). I compensate partially by hac
> - Waits for a full line before proceeding. Implementing critical word
>   first isn't complicated, but the extra tracking is likely to hurt
>   timing.
>
> Tommy
>
Hi Tommy,

I saw the DE2-70 board on your web site. I hope to get to play with a
DE2-70 board shortly for some image processing applications. I've
downloaded a snap shot of your design files, so I might be able to try
it out soon.

Can you possible explain random replacement a little better and excuse
my ignorance, but what does LRU stand for ?

John.

--
http://www.johnkent.com.au
http://members.optusnet.com.au/jekent

jalobaba wrote:
> You all might be interested in this announcement:
>    http://www.eetimes.com/news/design/showArticle.jhtml?articleID=220301386
>
>
Hi Jalobaba,

EETimes had a muticore virtual conference earlier this year, and more
recently a SoC virtual conference. 11am US EST is about 1am in the
morning here in Australia, so you have to be keen to stay up all night
to take part.

John.

--
http://www.johnkent.com.au
http://members.optusnet.com.au/jekent

You all might be interested in this announcement:
    http://www.eetimes.com/news/design/showArticle.jhtml?articleID=220301386

--- On Sun, 10/4/09, John Kent <jekent@...> wrote:
> > I was having a discussion with Tommy Thorn on this list back in April
> > this year about his MIPS compatible YARI CPU that used 4-way
> > associative instruction and data cache. That might give you some
> > design clues.
> >
> > http://yari.thorn.ws/YARI/Introduction.html
> >
> > I've seen very little activity on this list since then. I hope my
> > email address has been working.

Thanks for the pitch. I've been very busy since, but there are a few
changes in the "pipeline": SDRAM support for DE2-70 and SSRAM support
for ML-401.

There is definitely a lack of DDR controllers. This is truly a Frequently
Asked Question. A while back there was a posting of a port of an Open Cores DDR
controller to one of the Digilent Spartan 3 boards. I got it
running on the Spartan 3S1600 board.

All modern dynamic RAM are designed for caches. The data cache and instruction
cache in YARI should be fairly straight forward to follow, but they also aren't
particularly sophisticated. In particular they:
- Use random replacement. There is a request for LRU replacement for real-
   time reasons.
- Are write through caches. Implementing a write-back cache requires an
   additional bitmap for dirty lines. (Also the line replacement policy
   design space grows more interesting). I compensate partially by hac
- Waits for a full line before proceeding. Implementing critical word
   first isn't complicated, but the extra tracking is likely to hurt
   timing.

Tommy

On Wed, 07 Oct 2009 00:15:10 +1100, you wrote:

>Jon, Richard, Hellwig, Andreas, and others,
>
>You might like to check out Henk Gooijen's PDP-11 web site. I think he
>might have been machining his own front panels ... I'm not 100% sure.
>
>http://www.pdp-11.nl/

Okay.  Now I'm impressed  I wonder if Henk would be interested in
adopting me!  ;)

Jon

Jon, Richard, Hellwig, Andreas, and others,

You might like to check out Henk Gooijen's PDP-11 web site. I think he
might have been machining his own front panels ... I'm not 100% sure.

http://www.pdp-11.nl/

John.

Jon Kirwan wrote:
>
> I'm wondering where one might come across an old PDP-11/45 or
> PDP-11/70 front panel.  The switch system, at the very least, would be
> nice to have.  Probably hard to come across, though.
>
> Jon
>
>

--
http://www.johnkent.com.au
http://members.optusnet.com.au/jekent

On Mon, 2009-10-05 at 11:16 -0700, Jon Kirwan wrote:

> I just don't like a keyboard and 7-seg display system. If I accepted
> that much, I'd probably go with the bootstrap rom and a serial port.
> That way I can use whatever I have handy and it doesn't take up much
> space, inherently, and I get to use real characters and not just what
> I'm stuck with regarding the 7-seg displays (not much, really.) Plus,
> I can add function, easily, without changing hardware.

ECO32 has exactly that: a bootstrap ROM (stored in
the Flash on the XESS board that also holds the
bitstring to initialize the FPGA) communicating to
a terminal (or a terminal emulation) over a serial
line. There are commands to read and alter register
contents as well as memory locations, set a breakpoint,
single-step instructions, run a program, boot from
the IDE disk, inspect and modify the TLB contents,
and other useful stuff for bringing up a new system.

Hellwig

Sorry if this is duplicated - I seem to have
a problem with sending mail.

On Mon, 2009-10-05 at 11:16 -0700, Jon Kirwan wrote:

> I just don't like a keyboard and 7-seg display system. If I accepted
> that much, I'd probably go with the bootstrap rom and a serial port.
> That way I can use whatever I have handy and it doesn't take up much
> space, inherently, and I get to use real characters and not just what
> I'm stuck with regarding the 7-seg displays (not much, really.) Plus,
> I can add function, easily, without changing hardware.

ECO32 has exactly that: a bootstrap ROM (stored in
the Flash on the XESS board that also holds the
bitstring to initialize the FPGA) communicating to
a terminal (or a terminal emulation) over a serial
line. There are commands to read and alter register
contents as well as memory locations, set a breakpoint,
single-step instructions, run a program, boot from
the IDE disk, inspect and modify the TLB contents,
and other useful stuff for bringing up a new system.

Hellwig

re: console switches

I think the primary purpose is in allowing examine-deposit and single stepping. 
Sure, there are some programs that get some switch settings but I haven't done
that kind of thing since my 1130 days.

Even if I used an LCD for display, a keypad for entry and a few toggle switches,
I could live with it.

In fact, using the LCD display allows the running core to decide what
information to display and where to display it.

I suppose a monitor with a VGA terminal is the next 'upgrade' but that just
doesn't make a nice front panel.

I need to spend more time thining about this.  I hadn't thought I would be
messing around with a 32 bit core so I haven't fully digested the ramifications.

Richard

On Mon, 05 Oct 2009 17:54:59 -0000, you wrote:

>
>
>--- In fpga-cpu@yahoogroups.com, Jon Kirwan <jonk@...> wrote:
>
>> Wasn't the link for a verilog translator?  I assume XST accepts that
>> but the sfl2vl was noted as verilog, not VHDL, on that web page.  Does
>> sfl2vl produce VHDL, as well?
>
>When you install the entire package, you get sfl2vl and sfl2vh which
>are scripts that invoke sfl2vlbin.exe.  sfl2vh adds a -vhdl option.

Got it.

>> I'm wondering where one might come across an old PDP-11/45 or
>> PDP-11/70 front panel.  The switch system, at the very least, would be
>> nice to have.  Probably hard to come across, though.
>>
>> Jon
>
>It would be very nice to either buy such a panel or build something
>similar.  That's one of the reasons I am looking at multi-boot for
>the FPGA.  I could build a panel like the PDP11 or even one like the
>Altai 8800.  Lots of switches and lights.  It would work for just
>about any 16 bit core.

The Altair 8800 used metal, bat-handle switches.  Quite frankly, using
it is like learning to play guitar -- you need callouses on your
fingers or else it will start to hurt.  Been there, as I built and
used one for years.  By comparison, the IMSAI 8080 front panel was a
dream on the fingers.  Wonderful to use.

I'm fine with 16-bit cores, by the way.  Possibly with very simple
memory expansion controllers.  Could go with something akin to the x86
paging system, I suppose, which permits wider physical addresses (36
bit, here) than the basic register size (32 bit.)  But all this is
just hobby fun to me.

>Looking at the ECO-32 core, I might want to rethink how that panel
>should look.  I think I will give up on discrete LEDs and an octal
>LED layout probably doesn't make it either.  Probably the best scheme
>is to use 8 digit 7 segment displays with one of the Maxim controller
>chips.  I already use this chip for my 2 row 8 digit display.

Yuk.  I'm not there.  I like front panels aka HP2116, PDP-11/70, IMSAI
8080.  Real switches per bit, physical, snap, exactly where you last
left them, etc.

>Console switch entry seems workable in a 16 bit environment.  It gets
>out of hand for a 32 bit machine.  I suspect that a hex keypad would
>be a better solution.

Okay.  I grant that at 32 bits, you are in a world of hurt with
switches unless you grew another arm and hand, or two.  Or rolled into
a fetal position and used hands and feet!  ;)

>Now, as the FPGA is controlling all this stuff, it would be possible
>for the PDP-11 core to define everything as octal and the other cores
>to define everything as hex.

I just don't like a keyboard and 7-seg display system.  If I accepted
that much, I'd probably go with the bootstrap rom and a serial port.
That way I can use whatever I have handy and it doesn't take up much
space, inherently, and I get to use real characters and not just what
I'm stuck with regarding the 7-seg displays (not much, really.)  Plus,
I can add function, easily, without changing hardware.

>The neatest solution I can come up with is a touch screen display.
>There is absolutely no reason that the register contents need to be
>presented in strictly real time.  You can't see the lights blink
>anyway.  I nice little touch screen would be perfect.  Add a menu
>system so you can get to the 'keypad' and you're good to go.

Tolerable.  Though it will never have the feel of a switch panel.  And
the touch screens I've used before are just not 'fast' and 'reliable'
like mechanical switches.  It has benefits and downsides.  It's not
'perfect'.  But I could maybe live with it.

Jon

--- In fpga-cpu@yahoogroups.com, Jon Kirwan <jonk@...> wrote:

> Wasn't the link for a verilog translator?  I assume XST accepts that
> but the sfl2vl was noted as verilog, not VHDL, on that web page.  Does
> sfl2vl produce VHDL, as well?


When you install the entire package, you get sfl2vl and sfl2vh which are scripts
that invoke sfl2vlbin.exe.  sfl2vh adds a -vhdl option.


> I'm wondering where one might come across an old PDP-11/45 or
> PDP-11/70 front panel.  The switch system, at the very least, would be
> nice to have.  Probably hard to come across, though.
>
> Jon
>

It would be very nice to either buy such a panel or build something similar. 
That's one of the reasons I am looking at multi-boot for the FPGA.  I could
build a panel like the PDP11 or even one like the Altai 8800.  Lots of switches
and lights.  It would work for just about any 16 bit core.

Looking at the ECO-32 core, I might want to rethink how that panel should look. 
I think I will give up on discrete LEDs and an octal LED layout probably doesn't
make it either.  Probably the best scheme is to use 8 digit 7 segment displays
with one of the Maxim controller chips.  I already use this chip for my 2 row 8
digit display.

Console switch entry seems workable in a 16 bit environment.  It gets out of
hand for a 32 bit machine.  I suspect that a hex keypad would be a better
solution.

Now, as the FPGA is controlling all this stuff, it would be possible for the
PDP-11 core to define everything as octal and the other cores to define
everything as hex.

The neatest solution I can come up with is a touch screen display.  There is
absolutely no reason that the register contents need to be presented in strictly
real time.  You can't see the lights blink anyway.  I nice little touch screen
would be perfect.  Add a menu system so you can get to the 'keypad' and you're
good to go.

Richard