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 50450

Article: 50450
Subject: Re: Tiny Forth Processors
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Wed, 11 Dec 2002 14:54:48 +1300
Links: << >>  << T >>  << A >>
Ralph Mason wrote:
> 
<snip
> The slowness comes in because of the work the stack machine must do to
> perform that add
> 
> Fetch op one from stack (dec sp )
> Fetch op two from stack (dec sp)
> Add ops
> Push result to stack ( inc sp)
> 
> By my count this is 4 cycles, although I suppose you could use a dual port
> stack and pop the arguments in one cycle. Although this increases the area
> of the design, which doesn't fit with what I want to acheieve. It doesn't
> look like it lends itself well to any kind of
> pipelining either.

What if you use Sync & Dual Port memory for the stack ? 
then this could become

 Fetch op one from stack (dec sp )
 tos := POP (operator) tos

the last line is a merge of 
> Fetch op two from stack (dec sp)
> Add ops
> Push result to stack ( inc sp)

no need to change SP, and separate Read.Write ports, plus Sync memory,
can make this very fast.

-jg

Article: 50451
Subject: Re: Pierce Crystal Oscillator in Cypress 37128 CPLD
From: "Clyde R. Shappee" <clydes@world.std.com>
Date: Tue, 10 Dec 2002 20:58:57 -0500
Links: << >>  << T >>  << A >>
To answer Ray's response, Yes I have done this in a production design, to save
cost.  I did, however option the board for an oscillator, in case there was
trouble... This was in an Altera part and there were no problems in
production.  Waveforms looked nice.  This was at 2.4576MHz.

The present design is a one off, and the 32kHz is an option only....  I have
since discovered a wiring error on the board, and I am sure that correcting
that will get me going.

Thanks for the response.

Clyde

Jim Granville wrote:

> Clyde R. Shappee wrote:
> >
> > Hello all,
> >
> > I am building an oscillator in a Cypress 37128 device which is the
> > standard inverter parallel resonant circuit.  I have done this dozens of
> > times in other programmable logic devices, as well as discrete gates.
> >
> > The frequency of operation is 32.768kHz.
> >
> > I have a 1 Megohm resistor across the crystal to start it up, standard
> > load capacitors yielding the required 12.5 pF load, and a resistor in
> > series  with the crystal to limit the power.  This resistor, in a
> > previous job required >>> 100k <<<< which was high in my experience.  I
> > have experimented with this resistor and the startup one, but cannot get
> > the oscillator to go.  I have tried 0 to 100 K for the series resistor.
> >
> > Does anyone here have experience with a Pierce oscillator at this
> > frequency in this device?  I did not expect this problem at all.... or I
> > would have designed in a discrete transistor oscillator that I know
> > works.
> >
> > Clyde
>
>  It's a bit unclear - I presume this does not actually work, and thus
> the question ?
>
>  When you say 'dozens' does that mean at 32KHz, and CPLD, or something
> else ?
>
>  Getting even a HCU04, or a uC XTAL Buffer, to oscillate at 32.768KHz
> is not trivial.
>  You need low drive currents ( hi output impedance ) to get the
> phase shifts needed.
>
>  That's why the uC that target 32Khz, have special 'sub 100Khz' buffer
> stages.
>
>  A transistor can oscillate OK at 32KHz, but lacks the slew rate to
> reliably clock a CPLD, so will need a Schmitt buffer.
>  Low slew causes a number of problems
> - it can multi-clock due to ground bounce
> - it can give rise to transistion oscillations ( > 100MHz )
> - it can have significant linear-mode thru currents (mA region)
>
> -jg


Article: 50452
Subject: Re: vlsi implementation of multipliers
From: "del cecchi" <dcecchi@msn.com>
Date: Tue, 10 Dec 2002 20:18:20 -0600
Links: << >>  << T >>  << A >>

"john jakson" <johnjakson@yahoo.com> wrote in message
news:adb3971c.0212092316.46f7e4a8@posting.google.com...
> As another old turd I can also recommend doing it the way all us old
> timers did.
>
> Grab some high quality tech color pens, at least a half dozen colors
> say using the industry std red/green/blue/black for the

SNIP
>
> When you get really good, you won't even need the pen/paper, you can
> just do it in yer noggin, and when you have figured the basic
> placements, capture with one of the above tools. After all that you
> will be set for lifetime employment!

Then you can start cutting Rubylith with your xacto knife.  Hot Damn.
It's 1967 all over again.  :-)

If you can find a copy of "mead and conway" it isn't bad either.

del cecchi



Article: 50453
Subject: Re: FPGA/PCI on low budget
From: "Pete Ormsby" <faepeteDELETETHIS@attbi.com>
Date: Wed, 11 Dec 2002 03:21:47 GMT
Links: << >>  << T >>  << A >>
As long as we're striving for accuracy here, the Altera product lineup looks
like this:

Apex 20KE/C (and earlier devices): 1 FF per IO cell
Mercury, Cyclone: 3 FF per I/O cell
Apex II, Stratix, StratixGX: 6 FF per I/O cell

And, as long as we're talking PCI, note that Stratix and StratixGX devices
have a special Fast Regional Clock that seems pretty much designed
specifically to handle PCI IRDY and TRDY signals.

-Pete-

Kevin Brace <kev3inbrac5eusen7et@ho9tmail.c1om> wrote in message
news:at5s40$e7p$1@newsreader.mailgate.org...
> Ray,
>
> I looked at Altera datasheets, and APEX II, Mercury, Stratix, and
> Cyclone have more than one FF per IOE, but APEX20K family (APEX20K,
> 20KE, and 20KC) have only one FF per IOE.
> However, 20KE and 20KC allows the IOE FF to be asynchronously preset
> which is important for PCI control signals because most of them are
> active low (i.e., FRAME#).
>
>
>
> Kevin Brace (If you want to respond to what I wrote, I prefer if you
> will do so within the newsgroup.)
>
>
>
> Ray Andraka wrote:
> >
> > This is only an issue for the 10K and its derivatives.  20K, mercury and
stratix have 3 flip-flops
> > per IOE, one for each direction and one for the tristate.
> >
> >
> > --
> > --Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930     Fax 401/884-7950
> > email ray@andraka.com
> > http://www.andraka.com
> >
> >  "They that give up essential liberty to obtain a little
> >   temporary safety deserve neither liberty nor safety."
> >                                           -Benjamin Franklin, 1759



Article: 50454
Subject: Re: Some boards for designers...
From: CBFalconer <cbfalconer@yahoo.com>
Date: Wed, 11 Dec 2002 03:41:58 GMT
Links: << >>  << T >>  << A >>
Seiran wrote:
> 
>    Part 1.1    Type: Plain Text (text/plain)
>            Encoding: 7bit

You will get more response if you post in text.  Html does not
belong in newsgroups, and is often automatically deleted by the
better ISPs.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!


Article: 50455
Subject: Re: Some boards for designers...
From: Seiran <petikian01@rogers.com>
Date: Wed, 11 Dec 2002 03:51:31 GMT
Links: << >>  << T >>  << A >>
OK!  Here it is:

Hi!
Dear Friends.

I hope my message may be  interesting for this group. (If it isn't then
just ignore it.)

Our company started to produce very small size FPGA and microcontroller
boards.
The sizes are small enough to drop all in your "overloaded" notebook's
bag.
All boards powered from USB, so no external power source need. It's
really convenient
when you are going to demonstrate your design with your laptop only.
You can use them as evaluation board or fit them on your own boards as a
component.
Also you can buy universal prototyping board and low price JTAG cable
for downloading
XILINX FPGA's and flash ROM.

See our web site.  www.seytronix.com

Some details and design examples will come soon.
(I've just started to setup the site and any suggestion is appreciated!)

Thanks!

   Seiran Petikian
   seiran@seytronix.com
   petikian01@rogers.com



CBFalconer wrote:

> Seiran wrote:
> >
> >    Part 1.1    Type: Plain Text (text/plain)
> >            Encoding: 7bit
>
> You will get more response if you post in text.  Html does not
> belong in newsgroups, and is often automatically deleted by the
> better ISPs.
>
> --
> Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
>    Available for consulting/temporary embedded and systems.
>    <http://cbfalconer.home.att.net>  USE worldnet address!


Article: 50456
Subject: Re: hardware image processing - log computation
From: Ray Andraka <ray@andraka.com>
Date: Wed, 11 Dec 2002 04:16:41 GMT
Links: << >>  << T >>  << A >>
Depends on the accuracy you desire and the resources at hand.  The quick and
dirty log I mentioned before is both faster and smaller than the restoring
arithmetic method described by Israel Koren in his book.

"Normand Bélanger" wrote:

> I'm currently working on an "FPU" like this (i.e. LNS computations).
> The best way I know of computing a LOG is described in Prof. Koren
> Computer arithmetic book in chapter 9 (if I recall correctly). It is also
> fairly easy to implement if you don't mind a significant latency.
>
>    Good luck,
>
>       Normand

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 50457
Subject: Re: State of the PCB world
From: Kevin Brace <kev3inbrac5eusen7et@ho9tmail.c1om>
Date: Tue, 10 Dec 2002 22:29:09 -0600
Links: << >>  << T >>  << A >>


Thomas Womack wrote:
> 
> This may be an incoherent request, but I'll go ahead.
> 
> When I last played with electronics, resistors were little cylindrical
> things with long wire legs, and ICs had at most forty pins, which came
> out of the side at convenient 2.54mm spacing; you could design on
> bread-board. If you wanted to connect to a computer, you used the
> parallel port, or the four-channel analogue-digital converter on the
> BBC Micro joystick port. If you were really advanced, you might try to
> build a two-layer PCB with little metal fingers at the bottom to plug
> into an ISA slot on a PC.


Thomas,

About 5 years ago, I purchased an ISA bus prototype breadboard so that I
can make an AdLib compatible sound card.
I never finished that project because I didn't know anything about how
to deal with the analog portion of the circuit (And I still don't know
anything about analog circuit to date . . .), but anyhow, I connected
Yamaha's YM3812 FM sound chip to the board with some TTL chips like
74LS245 and 74LS688, and was able to do read and write access to the
chip from my computer via I/O port 0388H and 0389H.
Since then I have lost the board, and cannot find it . . .
I hope to find it someday so that I can finish the project.



> How do you interface widgets to a computer nowadays? Are there chips
> which can convert USB or PCI to something easier to contemplate; is it
> practical for a hobbyist to connect things to the PCI bus?
> 
> Which is the right group for me to be asking these questions in?
> 
> Tom


        If you wanted to connect something to the PCI bus, you will
probably want to purchase a PCI prototype board, rather than making your
own PCB.
More than a year ago, I purchased a Spartan-II PCI development kit from
a company called Insight Electronics to test a PCI IP core I developed
in Verilog HDL.
Because I was poor, I didn't have access to an oscilloscope or a logic
analyzer, so I had to do almost all the testing on an HDL simulator
(ModelSim XE-Starter from Xilinx which is free).
When I first fired up the board, the configuration register block of the
PCI IP core worked fine, and Windows 98 automatically detected the
board, but as soon as I tried to access the I/O registers mapped by the
BIOS, the computer froze.
Because I didn't have an oscilloscope or a logic analyzer, I didn't know
what was going on, and from there I had to waste two and a half weeks
trying to figure out why the computer will crash as soon as I accessed
the I/O registers, but not the configuration register block.
The PCI IP core was working perfectly fine during an RTL simulation
(Verilog HDL code simulation).
Ultimately, I figured out the problem by simulating the logic generated
by the HDL synthesis tool (Post P&R simulation), and found that several
important control signals were going undefined, which probably meant
that the HDL synthesis tool incorrectly synthesized the design.
Turned off bunch of optimizing sounding options, and the HDL synthesis
tool this time correctly synthesized the design (Redid the post P&R
simulation to make sure the simulation results agreed with the RTL
simulation's results. Other than the logic delay associated with the
post P&R simulation, the results matched.).
After that, I fired up the PCI card, and this time, the I/O register
access will no longer froze the computer, and was able to read and write
to the I/O registers correctly.
        Since then, Insight Electronics discontinued the card I
purchased, but recently released a newer PCI prototype card.

http://www.insight-electronics.com/cgi-bin/bvutf8/memec/scripts/local/mc_loc_b.jsp?Div=INSIGHT&Reg=AMERICAS&Country=UNITED_STATES&Lang=EN&EDOID=187428&Manu=XILINX


The newer card now costs $250 (Older one cost $145), but is still the
cheapest FPGA-based PCI prototype card available.
However, the problem of using this card is that, they are only selling
you the shell (hardware) only, and you need to separately obtain a PCI
IP core to use the board.
The board does come with a reference design, but is assumed by Insight
Electronics that the user will be using Xilinx's LogiCORE PCI IP core
which costs $2,000 for a single project license or $5,000 for a regular
license.
Currently, the only available option for poor hobbyists to use this type
of PCI prototype board will be to use Opencores.org's free PCI IP core,
but not too many people seem to be actively using it.
If Opencores.org's free PCI IP core doesn't work for you, you will have
to do develop your own PCI IP core, which is possible because I was able
to do it, but it will take several months to understand PCI and develop
the IP core.
Because of the PCI IP core problem, you might want to consider
purchasing a PCI prototype board with PLX Technology's PCI bridge and an
FPGA attached to it.
I know that PLX Technology sells prototype boards with their own chips,
but I am not sure they have one with an FPGA attached to it.
The big advantage of using PLX's chip will be that you don't have to
deal with the aforementioned nasty PCI IP core issues.
        Since we are talking of poor hobbyists here, we need to watch
how much money is being spent.
Here is how much I spent for my PCI project.


Insight Electronics Spartan-II 150 PCI development kit  $145
Related option board 1                                  $ 95
Related option board 2                                  $ 40
Parallel port JTAG programming cable                    $ 60
Tax + shipping for the above 4 items                    $ 40

PCI Local Bus Rev. 2.2 Specification                    $ 60
PCI Hardware and Software 4th Edition                   $110
PCI System Architecture 4th Edition                     $ 40

Several Verilog HDL texts                         about $200

Xilinx ISE WebPACK                                      free
ModelSim XE-Starter (Downloaded from Xilinx)            free
Electricity cost for downloading the two software       $2 (?) 
(Takes 15 hours with a 56K modem)
---------------------------------------------------------------
Total                                                   $792



        I have to admit, Xilinx giving out a complete FPGA development
environment helped save me a lot of money, or otherwise I would have had
to pay another $1,700 for software ($700 for ISE BASE-X and $1,000 for
ModelSim XE).
        Looking back at my PCI project, things have definitely gotten
tougher for hobbyists, considering that PCI bus is a lot more
complicated than ISA bus which means it takes a lot more time to learn
the bus protocol, and even hobbyists need to know HDL to realistically
design anything with an FPGA.
Furthermore, really poor hobbyist like myself who cannot afford an
oscilloscope or a logic analyzer need to rely more on a simulator to
make sure that the design will function correctly.
However, writing testbenches is the most boring aspect of the design
(Let's face it, everyone loves designing the circuits, but not testing
it.), and I don't really enjoy doing it.
Unfortunately, almost all the HDL books sold at bookstores like Borders
or Barnes & Noble largely remain an HDL syntax reference manual, and
lacks a real world project like "Let's develop a PCI IP core, and hook
it up to your computer!" that might motivate more people to get into the
wonderful world of hardware design or hobbyists electronics projects.



Kevin Brace (If you want to respond to what I wrote, I prefer if you
will do so within the newsgroup.)

Article: 50458
Subject: Re: Some boards for designers...
From: "Steven" <steven_vh@pandora.be>
Date: Wed, 11 Dec 2002 08:48:06 GMT
Links: << >>  << T >>  << A >>

"Seiran" <petikian01@rogers.com> wrote in message
news:3DF6E07D.A2778DC@rogers.com...
> [snip]
> See our web site.  www.seytronix.com
>
> Some details and design examples will come soon.
> (I've just started to setup the site and any suggestion is appreciated!)
>

Please get rid of the animated GIF: it's distracting, extremely annoying and
it gives a webpage an unprofessional look.



Article: 50459
Subject: Re: FPGA/PCI on low budget
From: hmurray@suespammers.org (Hal Murray)
Date: Wed, 11 Dec 2002 08:53:24 -0000
Links: << >>  << T >>  << A >>
>The 64 bit PCI supports 3v, and any motherboard with it will work with the 3v
>cards.  Some of the FPGA cards such as the ISI Osiris board require a 64 bit slot
>because they are 3v boards.  It is rare to find 32bit PCI motherboards with 3v
>support.

Thanks.

Is there some simple rule I've missed?  Are all 64 bit slots 3V only?
Are all 66 MHz slots 3V?

A friend at work pointed out that the SGI 320 is 3V only PCI.
They have enough troubles finding cards that they have a list
of known-to-work cards:
   http://www.btinternet.com/~sgi320/PCI.htm
I didn't see any cards with serial ports.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 50460
Subject: Re: Tiny Forth Processors
From: hmurray@suespammers.org (Hal Murray)
Date: Wed, 11 Dec 2002 09:32:42 -0000
Links: << >>  << T >>  << A >>
> A stack machine will require more cycles per instruction.  So by the cycles
> per interction metric they are slower.

That's not obvious to me.  What's an instruction?  Who cares?  Why
not measure time to execute a line of code?


> That's a point I like about stack machines. See the stack as a better, more
> efficient cach. And it's better predictable when it comes to real time
> systems.

Huh?  How are you measuring efficiency?  More predictable than registers?

-----

In the '70s and '80s, Xerox PARC did a lot of work on stack based
instruction sets.  It started with Mesa on the Alto.  The
Alto architecture wasn't designed for emulating Mesa, but it
worked pretty well after a lot of hard/clever work.

That was back in the days when memory was expensive.  Dick Sweet's
Stanford PHD thesis was on compressing code to save memory.
Most of normal code (and execution time) is load/store type
operations.  He worked on the instruction set used by Mesa.

After the Alto, Xerox built several machines designed to
emulate Mesa.

The Dandelion turned into the Star workstation.
The microcode was 40? bits wide, 2901 based.  The stack lived
in a small clump of registers someplace.  Maybe in the 2901, but
I'm not sure.  It wasn't very big.  The stack was empty between
lines of code. If the line of code the compiler was generating
got too deep, the compiler had to dump and restore the stack.
Parameters/results to/from subroutines were passed in the stack
which had nothing else in it.  Worked OK most of the time.

The Dorado was king of the workstations for a long time.  ECL.
It ran Cedar - Mesa on steroids.  The main difference was
a garbage collector, and microcode/opcodes to support reference
counting.  And a programming environement to support it and
take advantage of it.  The machine was big and noisy so they
actually lived down in the machine room with long cables up
to offices.


As far as I can tell, RISC/CISC/Stack is all lost in the noise.
Perhaps a good excuse to go drink beer and have religious arguments.

Use what fits your problems and skills.  A clever hacker can do
very good work, especially if he is having fun doing what he wants.
On the other hand, Intel's army of engineers is going a great job
of cranking out fast chips in spite of the horrible architecture
they have to use.


> And my thinking was, perhaps a stack machine meets these requirements better
> than a risc type machine.

How are you measuring goodness?

Pick a few sample problems and try them both.  Seems like a
good project for a class or computer club.


-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 50461
Subject: Re: Tiny Forth Processors
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Wed, 11 Dec 2002 11:57:01 -0000
Links: << >>  << T >>  << A >>
Hal Murray wrote

> As far as I can tell, RISC/CISC/Stack is all lost in the noise.
> Perhaps a good excuse to go drink beer and have religious arguments.
>
> Use what fits your problems and skills.  A clever hacker can do
> very good work, especially if he is having fun doing what he wants.
> On the other hand, Intel's army of engineers is going a great job
> of cranking out fast chips in spite of the horrible architecture
> they have to use.

Transputer.  Still being developed, built, and used.  A 500MHz
version in HDL was presented at the last DAC.

Seems to be a good fit for verious embedded problems, like the
problems this group focuses on.




Article: 50462
Subject: Re: Tiny Forth Processors
From: "Martin Schoeberl" <martin.schoeberl@chello.at>
Date: Wed, 11 Dec 2002 12:41:05 GMT
Links: << >>  << T >>  << A >>
Sorry, but my first statement was to simple and a mix of theory and praxis.
I'll try (as I can) to explain it in more detail:

> Acutally I'm currently looking at implemeting a stack based architecture
> along with a RISC architecture.  I think you miss the point a bit with
> your example.  You say that local varaiables are allocated to registers
> for the RISC example, but then force the stack based design to load to
> the stack.  Giving the stack based architecture the same advantage,
> that both operands are available at the top of the stack surely the
> optimised code would be :-
>
> add

As I know (perhaps I'm wrong) in theory every computing problem can be
solved with a stack architecture without local variables. But for procedural
languages you need two stacks: one for the operands and one for the return
addresses. When you mix them in one stack you have to load the function
parameters on the current operand stack.

And how is following example solved?

f(a) {
    b = 1-a;
    return b
}

assume paramters and return values on stack:

    push 1
    swap             -- one 'extra' stack manipulation is necessery
    sub
    return

Now to the practical thing:

The JVM is a little bit inconsistent on usage of the stack. For function
calls the parameters must be pushed on the stack. But in the called function
they are accessed as 'locals'. I think this point comes from (perhaps wrong)
anticipation of the language designers to use one stack for data
(parameters) and the return addresses.

So a simple function like:

int f(int a, int b) {
    return a+b;
}

translates to:

Method int f(int, int)
   0 iload_1
   1 iload_2
   2 iadd
   3 ireturn

And one really BAD thing of the Sun's Java compiler. It does NO stack
optimization! So a lot of stack-locals move are generated.

One example:

 int f(int a, int b, int c) {

  int x;
  x = a+b;
  return x+c;
 }
translates to this (even with -O options):

Method int f(int, int, int)
   0 iload_1
   1 iload_2
   2 iadd
   3 istore 4       // these two statements are really redundant
   5 iload 4
   7 iload_3
   8 iadd
   9 ireturn

I was really disappointed when starting with my Java processor. I played
around a little bit with hand optimization of JVM code. In one example
program execution time dropped on JOP and in Suns JVM in interpreting mode
for about 25%. But the execution time
of the JIT compiled program was LONGER!. In JDK 1.1 about 10% and in JDK 1.3
it was about 15 times slower!

Here is the complete example: http://www.jopdesign.com/perf.html

I think javac does no optimization to make it easier for JIT to compile JVM
stack code to a register machine. And the JIT assumes this simple minded
stack code for it's optimization.

I was looking arund to find some byte code optimizer, but have only found
this 'obfuscators'. No optimizer for the stack code.

> Further you might say that the stack access must be slower than a register
> file, since you require to access to the stack plus write-back.  But in

No. I assumed the same single cycle access time for 2 operands load and one
write on the stack as for two register load and one write.

I think this thread gets a little bit OT, perhaps we should move to
c.l.forth or c.l.j.machine

Martin
--
JOP - a Java Optimized Processor for FPGAs.
http://www.jopdesign.com



Article: 50463
Subject: Re: Tiny Forth Processors
From: "Martin Schoeberl" <martin.schoeberl@chello.at>
Date: Wed, 11 Dec 2002 12:49:13 GMT
Links: << >>  << T >>  << A >>
> The slowness comes in because of the work the stack machine must do to
> perform that add
>
> Fetch op one from stack (dec sp )
> Fetch op two from stack (dec sp)
> Add ops
> Push result to stack ( inc sp)
>
> By my count this is 4 cycles, although I suppose you could use a dual port
> stack and pop the arguments in one cycle. Although this increases the area
> of the design, which doesn't fit with what I want to acheieve. It doesn't
> look like it lends itself well to any kind of
> pipelining either.

I assumed these four operations in one single cycle. It's easy to implement
when TOS and TOS-1 are real register, that feed the alu. You only have to
spill and fill TOS-1 with a single port memory. For the design its easier to
use a memory with independent read and write port.

You can find a simple picture of that at: http://www.jopdesign.com/jop3.html

A is TOS, B is TOS-1 and the block named RAM is the rest of the stack. On an
operation that consumes one operand (like add) B is filled with the next
stack element and A is loaded with A op B. On a push instruction B is loaded
with A and the memory is filled with B.

Martin
--
JOP - a Java Optimized Processor for FPGAs.
http://www.jopdesign.com



Article: 50464
Subject: Urgent : Need help with VHDL modeling on Cypress's Warp 5.2
From: jagan_r@lycos.com (J R)
Date: 11 Dec 2002 05:18:29 -0800
Links: << >>  << T >>  << A >>
Hi everyone...
   I am not sure how to use a VHDL model I have already done in a
higher-level model. There seems to be no 'work' library concept in
Warp (on PC platform ) and so i am not sure how this can be done. All
I have recognized is that the compilation of a VHDL model leads to the
creation of a directory ( with the compiled contents I suppose ) with
the same name as the Model. Can someone help me out please ? I would
really appreciate it.

   Following are further details.

   In a directory X, I have created 'alu_types.vhd' and compiled it. I
want to use this model in another model 'alu.vhd' ( present in the
same directory ). Normally we can do this using

       use work.alu_types.all

       at the start of the alu.vhd file. ( if a system - 'work'
library used).

   I need to resolve this urgently. If someone could please help me
out with this, it would be great.

Thanks,
Jagan
 
----------------
alu_types.vhd
----------------

--package that defines ALU function code types and allowed values
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

package alu_types is
  subtype alu_fun is std_logic_vector(3 downto 0);
  
  constant simple_add : alu_fun :="0000";
  constant carry_add : alu_fun :="0001";
  constant andop : alu_fun :="0010";
  constant simple_sub : alu_fun :="0011";
  constant carry_sub : alu_fun := "0100";
  constant arith_left_shift : alu_fun := "0101";
  
end package alu_types;

--------------------------------------------------
 The first few lines of the alu.vhd model are below.

----------------
alu.vhd
----------------

--entity and architecture of ALU

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use work.alu_types.all;           -- <-- PROBLEM LINE !!!
-- The compiler shows errors in this line since it's unable to find
the
-- compiled alu_types model

entity alu is
 port(
   oper1:in std_logic_vector(15 downto 0);
   oper2:in std_logic_vector(15 downto 0);
   typeofop:in alu_fun;
   answer:out std_logic_vector(15 downto 0);
   halfcarry,sign,zero,overflow,carry:out std_logic
   );
end entity alu;

architecture behavior of alu is
begin
   calculate:process (oper1,oper2,typeofop) is
   ....................
   ....................      
--------------------

Article: 50465
Subject: Re: Xilinx ISE 5.1 Wait for statement unsupported??
From: javodv@yahoo.es (javid)
Date: 11 Dec 2002 05:43:07 -0800
Links: << >>  << T >>  << A >>
hello again,

Yes, I know that I need a simulator. I use ISE with modelsim. I think
that maybe the problem is with the WAVE_GEN module (it is the module
responsible for placing transactions and events in the other modules
input). When I simulate it (functional) I don't see any signal so
probably something is wrong, the clock generation??. Here I place the
code of the learning example.

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

--  Uncomment the following lines to use the declarations that are
--  provided for instantiating Xilinx primitive components.
--library UNISIM;
--use UNISIM.VComponents.all;

entity WAVE_GEN is
    Port ( BUSY : in std_logic;
           DATV : in std_logic;
           DI : in std_logic_vector(7 downto 0);
           CLK : out std_logic;
           DO : out std_logic_vector(7 downto 0);
           POP : out std_logic;
           PUSH : out std_logic;
           RST : out std_logic);
end WAVE_GEN;

architecture Behavioral of WAVE_GEN is
  signal CLK_tmp: std_logic;
  constant TCLK: time := 50 ns;
  constant DAT0: std_logic_vector(7 downto 0) := "00000000";
  constant DAT1: std_logic_vector(7 downto 0) := "00000001";
  constant DAT2: std_logic_vector(7 downto 0) := "00000010";


begin
  
  RST <= '1', '0' after 30 ns;
  CLK <= CLK_tmp;
  
  process begin
    CLK_tmp <= '0', '1' after TCLK/2;
	 wait for TCLK;
  end process;
  
  process
  begin
    PUSH <= '0'; DO <= DAT0; POP <= '0';
	 wait for 40 ns;
	 wait until (CLK_tmp='0');
	 -- Push 1
	 PUSH <= '1'; DO <= DAT1; POP<='0';
	 wait until (CLK_tmp='0');
	 PUSH <= '0'; DO <= DAT0; POP <='0';
	 wait until (CLK_tmp='0' and BUSY='0');
	 -- Push 2
	 PUSH <= '1'; DO <= DAT2; POP<='0';
	 wait until (CLK_tmp='0');
	 PUSH <= '0'; DO <= DAT0; POP <='0';
	 wait until (CLK_tmp='0' and BUSY='0');	  
	 -- Pop 2
	 PUSH <= '0'; DO <= DAT0; POP<='1';
	 wait until (CLK_tmp='0' and DATV='1');
	 assert (DI=DAT2) report "read error" severity warning;
	 PUSH <= '0'; DO <= DAT0; POP <='0';
	 wait until (CLK_tmp='0');
	 -- Pop 1
	 PUSH <= '0'; DO <= DAT0; POP<='1';
	 wait until (CLK_tmp='0' and DATV='1');
	 assert (DI=DAT1) report "read error" severity warning;
	 PUSH <= '0'; DO <= DAT0; POP <='0';
	 wait until (CLK_tmp='0');
  end process;

end Behavioral;

Thanks anyway,

Javi


Ray Andraka <ray@andraka.com> wrote in message news:<3DF679EE.163C3774@andraka.com>...
> ISE is an implementation tool, not a simulator.  You need to use aldec, modelsim or the
> like to simulate.  Those tools recognize wait for.
> 
> javid wrote:
> 
> > Thanks for the responses, but I just want to make a functional
> > simulation not postplace&route so why is not possible to use wait for
> > statements (not synthesizable). My purpose was to simulate the design
> > not to implement it. So is it possible to make a functional simulation
> > and build a test bench or am I still wrong?
> >
> > Thanks a lot for your quick answers,
> >
> > Javi
> >
> > Ray Andraka <ray@andraka.com> wrote in message news:<3DF60EA9.5918A7D4@andraka.com>...
> > > Wait for is not a synthesizable construct.  Think about it, how would you
> > > build digital hardware that would 'wait for 40 ns'?  They key do doing
> > > good VHDL designs is to visualize the hardware you need to accomplish your
> > > task, then write the VHDL to produce that hardware.  Trying to start at a
> > > program type description and putting the intelligence to make hardware out
> > > of it on the synthesizer is at best going to give you poor results, or as
> > > you found out produce something unsynthesizable.
> > >
> > > javid wrote:
> > >
> > > > Hello,
> > > >
> > > > I have made a simple VHDL program that have three VHDL modules
> > > > (WAVE_GEN, CONTROLLER, RAM512). I have in my WAVE_GEN code "wait for
> > > > 40 ns;". The problem is that when I try to generate a symbol ISE tells
> > > > me " Wait for statement unsupported". I also have made a "TOP" VHDL
> > > > module that instantiate the three previous modules and interconnects
> > > > them with signals. This "TOP" module is for conecting the waves
> > > > generated by WAVE_GEN to the other VHDL modules. My problem here is
> > > > that when I simulate this TOP module I don't see any signal, etc. in
> > > > Modelsim window because this "TOP" module doesn't have ports. How can
> > > > I see the internal signals??
> > > >
> > > > Thanks a lot and regards,
> > > >
> > > > Javi
> > >
> > > --
> > > --Ray Andraka, P.E.
> > > President, the Andraka Consulting Group, Inc.
> > > 401/884-7930     Fax 401/884-7950
> > > email ray@andraka.com
> > > http://www.andraka.com
> > >
> > >  "They that give up essential liberty to obtain a little
> > >   temporary safety deserve neither liberty nor safety."
> > >                                           -Benjamin Franklin, 1759
> 
> --
> --Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com
> 
>  "They that give up essential liberty to obtain a little
>   temporary safety deserve neither liberty nor safety."
>                                           -Benjamin Franklin, 1759

Article: 50466
Subject: Re: hardware image processing - log computation
From: "Normand Bélanger" <belanger.no@sympatico.ca>
Date: Wed, 11 Dec 2002 10:22:40 -0500
Links: << >>  << T >>  << A >>
Agreed. I was under the impression that precision was needed in this
case so I suggested this.

   Normand

"Ray Andraka" <ray@andraka.com> a écrit dans le message de news:
3DF6BC7D.B9D0BB5A@andraka.com...
> Depends on the accuracy you desire and the resources at hand.  The quick
and
> dirty log I mentioned before is both faster and smaller than the restoring
> arithmetic method described by Israel Koren in his book.
>
> "Normand Bélanger" wrote:
>
> > I'm currently working on an "FPU" like this (i.e. LNS computations).
> > The best way I know of computing a LOG is described in Prof. Koren
> > Computer arithmetic book in chapter 9 (if I recall correctly). It is
also
> > fairly easy to implement if you don't mind a significant latency.
> >
> >    Good luck,
> >
> >       Normand
>
> --
> --Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com
>
>  "They that give up essential liberty to obtain a little
>   temporary safety deserve neither liberty nor safety."
>                                           -Benjamin Franklin, 1759
>
>



Article: 50467
Subject: ispDesignEXPERT installation
From: "Mathew Orman" <orman@tyrellinnovations.com>
Date: Wed, 11 Dec 2002 16:32:05 +0100
Links: << >>  << T >>  << A >>
Hallo everyone..

I have a problem installing ispDesignEXPERT v7.1
on WinXP.
The license.dat file I've just received from Lattice support
fails to initialize the essential features.
If anyone have experienced installing this package,
please help me if you can!

Sincerely,

Mathew Orman




Article: 50468
Subject: Re: FPGA startup events
From: hristostev@yahoo.com (hristo)
Date: 11 Dec 2002 07:39:25 -0800
Links: << >>  << T >>  << A >>
as a follow up to my previous messages
will the user clock be running during the Fpga startup phase?
we have read a lot about the GSR slow propagation through the chip, so
why not just delay the input data for some clock cyles till we will be
sure that GSR has run through all the chip?

Article: 50469
Subject: Re: Some boards for designers...
From: Laurent Gauch <laurent.gauch@amontec.com>
Date: Wed, 11 Dec 2002 16:52:09 +0100
Links: << >>  << T >>  << A >>
Nice board, but the 400ma is no enougth for the X2S100E FPGA. Certainly 
OK in some cases, but a 500 ma minimum is specified by Xilinx for the 
FPGA download!!!

Seiran wrote:
> Hi!
> Dear Friends.
> 
> I hope my message may be  interesting for this group. (If it isn't then 
> just ignore it.)
> 
> Our company started to produce very small size FPGA and microcontroller 
> boards.
> The sizes are small enough to drop all in your "overloaded" notebook's bag.
> All boards powered from USB, so no external power source need. It's 
> really convenient
> when you are going to demonstrate your design with your laptop only.
> You can use them as evaluation board or fit them on your own boards as a 
> component.
> Also you can buy universal prototyping board and low price JTAG cable 
> for downloading
> XILINX FPGA's and flash ROM.
> 
> See our web site.  www.seytronix.com <comp.arch.embedded>
> 
> Some details and design examples will come soon.
> (I've just started to setup the site and any suggestion is appreciated!)
> 
> Thanks!
> 
>    Seiran Petikian
>    seiran@seytronix.com
>    petikian01@rogers.com
> 


Article: 50470
Subject: Re: Some boards for designers...
From: larwe@larwe.com (Lewin A.R.W. Edwards)
Date: 11 Dec 2002 08:00:12 -0800
Links: << >>  << T >>  << A >>
Hi Seiran,

> Our company started to produce very small size FPGA and microcontroller
> boards.

Interesting items. However while you're setting up merchant facilities
for a "real" web store, I suggest you try using Paypal so people can
order online with a credit card. You'll get more orders :)

Article: 50471
Subject: partial Bitstream Size in Virtex-II
From: Heiko Kalte <kalte@hni.upb.de>
Date: Wed, 11 Dec 2002 17:19:28 +0100
Links: << >>  << T >>  << A >>
Hi,
I am trying to estimate the partial bitstream size of a 201 slices
design part in a Virtex-II 500. I did a rough estimation for a
Virtex600E. Therefor I divied the Slices by 2 to get the Number of CLBs.
Afterward I divied this by the number of CLBs in a Column for a
Virtex600E. This leads to at least 2 columns (or more depends on the
floorplan). Each CLB column consists of 48 frames and each frame of
960bit. Adding some initialization leads to 93504 config bit.

The problem is that I did not found out the frames per CLB in a Virtex2,
there must be more than 48 because there are 4 slices in a CLB.
Additionally I nead the bit per frame for a Virtex-II 500. 
Please Help me.
Heiko


By the way is this calculation correct?

  
-- 
---------------------------------------------------------------
Dipl. Ing. H. Kalte               |
HEINZ NIXDORF INSTITUTE           | Office: F1.213
System and Circuit Technology     | Fon: +49 (0)5251 60-6459
Fürstenallee 11                   | Fax: +49 (0)5251 60-6351
33102 Paderborn, Germany          |
---------------------------------------------------------------
mailto:kalte@hni.uni-paderborn.de
http://wwwhni.uni-paderborn.de/sct/
---------------------------------------------------------------

Home of the RAPTOR Rapid Prototyping Systems
http://www.RAPTOR2000.de/

---------------------------------------------------------------

Article: 50472
Subject: Re: FPGA/PCI on low budget
From: "Austin Franklin" <austin@da98rkroom.com>
Date: Wed, 11 Dec 2002 11:26:12 -0500
Links: << >>  << T >>  << A >>
Hi Ray,

That may not be quite right.  64 bit has nothing to do with 3V or 5V, it's
66MHz that's 3V only.  64 bit can be either 3V or 5V, as it is merely adding
32 bits to the data path, with no change in signaling or timing.

I have seen motherboards that support 64 bit, but are only 5V 33MHz.

Regards,

Austin

"Ray Andraka" <ray@andraka.com> wrote in message
news:3DF580B1.FEDF0293@andraka.com...
> The 64 bit PCI supports 3v, and any motherboard with it will work with the
3v
> cards.  Some of the FPGA cards such as the ISI Osiris board require a 64
bit slot
> because they are 3v boards.  It is rare to find 32bit PCI motherboards
with 3v
> support.
>
> Hal Murray wrote:
>
> > > Did 3V PCI ever take off
> >
> > Thanks for all the feedback.  Sorry my question wasn't clear.
> >
> > There are two possible meanings for 3V.  One is power.  The other
> > is the signaling level.
> >
> > First, the power stuff:
> >
> > The PCI connector has power pins for 5V, and 3.3V, and also a
> > few more pins for IO power.  They are either 3 or 5, depending
> > upon the signaling voltage, the idea being that you can wire
> > them to the supply rail for your IO pads and make a board that
> > supports either 3V signaling or 5V, depending upon the power the
> > motherboard supplies on those pins.
> >
> > The PCI connector has a plug that matches with a cutout on the
> > board.  The plug goes in either of two positions (turn the connector
> > around), one for 5V signaling, the other for 3V.  So in theory,
> > you can make three types of cards.  The normal card in wide use
> > is 5V signaling, though they may only drive the outputs with a
> > 3V CMOS driver.  You can also make 3V only card by putting the
> > cutout on the other end of the card.  You can also make 3V/5V
> > cards by cutting out both slots and maybe wiring the IO pad
> > rail on your chip to the IO supply from the PCI connector.
> >
> > I've never seen any 3V or dual cards.
> >
> > The main question I was trying to ask was if anybody had seen
> > any 3V or dual signaling level cards.  If so, I might think more
> > about taking advantage of that.  Since I didn't see many
> > encouraging responses I'll probably but this on the back burner.
> >
> > Some early systems didn't actually supply any 3.3V power.  You
> > can dance around that with an on-board regulator.  I plan to
> > ignore that.  (But I'll check my systems first, just in case,
> > and listen for tales of troubles with not-so-early boards.)
> >
> > Now for the signaling:
> >
> > The 3V signaling rules overlap the 5V rules enough so that a
> > card that drives high to 3V will work in a 5V system.  The
> > catch is that some other card driving to 5V on a system that
> > produces worst-case reflections might generate an 11V spike.
> > "5V tolerant" is the critical term for that.
> >
> > The Spartan-II is 5V tolerant but doesn't have DLLs.  The -IIE
> > has DLLs, but doesn't tolerate 5V signaling.
> >
> > Since 3V systems don't seem to be very popular, I probably won't
> > build a card expecting to find a 3V only slot.
> >
> > Several years ago, I put a scope on a system that had the connector
> > pegs set for 5V.  I never saw anything go over 3V.  Obviously that
> > depends upon what cards are plugged in.  Somebody could add an
> > old/evil card that really does drive to 5V.
> >
> > For hack/research systems it might make sense to use a FPGA that
> > wasn't 5V tolerant on a card that could be plugged into a 5V system.
> > You would have to remember to get out the scope before adding a card
> > that hadn't been tested yet.  I'm probably not desperate enough
> > to get the DLLs that I will do this.  (But I'm still scheming.)
> >
> > Thanks for the PLX suggestions.  Their web site expects me to
> > register before they give me data sheets so I'll put that on the
> > back burner.
> >
> > Thanks for the heads-up about using DLLs on PCI clocks.  Is
> > that a clear don't-do-that, or just another worm for the list?
> >
> > --
> > The suespammers.org mail server is located in California.  So are all my
> > other mailboxes.  Please do not send unsolicited bulk e-mail or
unsolicited
> > commercial e-mail to my suespammers.org address or any of my other
addresses.
> > These are my opinions, not necessarily my employer's.  I hate spam.
>
> --
> --Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com
>
>  "They that give up essential liberty to obtain a little
>   temporary safety deserve neither liberty nor safety."
>                                           -Benjamin Franklin, 1759
>
>



Article: 50473
Subject: Re: hardware image processing - log computation
From: Ray Andraka <ray@andraka.com>
Date: Wed, 11 Dec 2002 16:35:23 GMT
Links: << >>  << T >>  << A >>
When I read imaging application, I was assuming 8 or 10 bit video, in which case
a 4 or 5 bit lookup is plenty.  If it is for medical or surveillance, it might
have more bits per pixel, in which case a higher precision log might be
desired.  Could use block ram as a LUT for 8 bit look-up if you have the block
ram to spare, or you could go to either a divider-like structure similar to the
one Isreal Koren presents in his book, or to a two tiered LUT approach.

"Normand Bélanger" wrote:

> Agreed. I was under the impression that precision was needed in this
> case so I suggested this.
>
>    Normand
>
> "Ray Andraka" <ray@andraka.com> a écrit dans le message de news:
> 3DF6BC7D.B9D0BB5A@andraka.com...
> > Depends on the accuracy you desire and the resources at hand.  The quick
> and
> > dirty log I mentioned before is both faster and smaller than the restoring
> > arithmetic method described by Israel Koren in his book.
> >
> > "Normand Bélanger" wrote:
> >
> > > I'm currently working on an "FPU" like this (i.e. LNS computations).
> > > The best way I know of computing a LOG is described in Prof. Koren
> > > Computer arithmetic book in chapter 9 (if I recall correctly). It is
> also
> > > fairly easy to implement if you don't mind a significant latency.
> > >
> > >    Good luck,
> > >
> > >       Normand
> >
> > --
> > --Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930     Fax 401/884-7950
> > email ray@andraka.com
> > http://www.andraka.com
> >
> >  "They that give up essential liberty to obtain a little
> >   temporary safety deserve neither liberty nor safety."
> >                                           -Benjamin Franklin, 1759
> >
> >

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 50474
Subject: Re: hardware image processing - log computation
From: "Normand Bélanger" <belanger.no@sympatico.ca>
Date: Wed, 11 Dec 2002 11:48:43 -0500
Links: << >>  << T >>  << A >>
"Open mouth, insert foot"

I went back to look at the previous messages on this thread and saw
that you are right. I was replying to Philip Freidin message in which he
talked about LNS and floating point so I assumed that FP like precision
was needed; I should have taken a look a the OP first.

   Sorry for the confusion,

      Normand

"Ray Andraka" <ray@andraka.com> a écrit dans le message de news:
3DF7699F.D0D3A7C8@andraka.com...
> When I read imaging application, I was assuming 8 or 10 bit video, in
which case
> a 4 or 5 bit lookup is plenty.  If it is for medical or surveillance, it
might
> have more bits per pixel, in which case a higher precision log might be
> desired.  Could use block ram as a LUT for 8 bit look-up if you have the
block
> ram to spare, or you could go to either a divider-like structure similar
to the
> one Isreal Koren presents in his book, or to a two tiered LUT approach.
>
> "Normand Bélanger" wrote:
>
> > Agreed. I was under the impression that precision was needed in this
> > case so I suggested this.
> >
> >    Normand
> >
> > "Ray Andraka" <ray@andraka.com> a écrit dans le message de news:
> > 3DF6BC7D.B9D0BB5A@andraka.com...
> > > Depends on the accuracy you desire and the resources at hand.  The
quick
> > and
> > > dirty log I mentioned before is both faster and smaller than the
restoring
> > > arithmetic method described by Israel Koren in his book.
> > >
> > > "Normand Bélanger" wrote:
> > >
> > > > I'm currently working on an "FPU" like this (i.e. LNS computations).
> > > > The best way I know of computing a LOG is described in Prof. Koren
> > > > Computer arithmetic book in chapter 9 (if I recall correctly). It is
> > also
> > > > fairly easy to implement if you don't mind a significant latency.
> > > >
> > > >    Good luck,
> > > >
> > > >       Normand
> > >
> > > --
> > > --Ray Andraka, P.E.
> > > President, the Andraka Consulting Group, Inc.
> > > 401/884-7930     Fax 401/884-7950
> > > email ray@andraka.com
> > > http://www.andraka.com
> > >
> > >  "They that give up essential liberty to obtain a little
> > >   temporary safety deserve neither liberty nor safety."
> > >                                           -Benjamin Franklin, 1759
> > >
> > >
>
> --
> --Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com
>
>  "They that give up essential liberty to obtain a little
>   temporary safety deserve neither liberty nor safety."
>                                           -Benjamin Franklin, 1759
>
>





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