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 138925

Article: 138925
Subject: Re: Nibz processor @ <570 MAXII LEs (16 bit generic specified), 20MHz
From: Jacko <jackokring@gmail.com>
Date: Sat, 14 Mar 2009 15:34:34 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 14 Mar, 20:28, Walter Banks <wal...@bytecraft.com> wrote:
> Jacko wrote:
> > Feel free to make a BSD 1 bit version of nibz. It may be smaller, but
> > will take 16 times as long to execute any code, yet will be bigger
> > than 1/16th the size. Therefore the computational use density
> > (instructions per cycle per area (m^2.s)^-1) will decrease. If
> > resources are really tight to maintain budget, and the lower execution
> > speed is not relevant for the task, then maybe the power efficiency
> > implications of computational use density (CUD) are not important
> > either.
>
> A very first order metric. I am not arguing for bit serial processors
> but the 16 to 1 makes an assumption that the bit serial is only
> implementing a 16 bit data path. A well designed bit serial instruction
> set would change the metrics on both the hardware and the
> performance.

Yes, this is true of any new metric idea. The general wanted measure
is to get bigger if less standing logic (not used in a cycle) exists.
It also should encompass motion forward through a piece of code, and a
lower area for function. Higher order versions of the metric should
include the amount of instruction RAM/ROM area to perform a particular
task, as this memory also contributes to the micro-watt per unit of
computation.

I do not think nibz is a perfect thing, but it comes from a lot of
hours spent thinking, this is one of the main reasons for zero
instruction overheads (in code size) of the design. As soon as the
base routine set is defined at 4 bits per instruction. The high zero's
exist only if the designer does not choose a different start vector
(0) or does not place the nibble RAM/ROM in a convienient place.

> You are correct that control overhead does not scale but
> bit serial processors can have a bunch of viable applications
> which has been my point. Low pin count to memory and I/O
> for example. The SDcard gives multiple gigabytes of memory
> with a few pins.

Yes they do have applications with low metal/interconnect track
designs. A direct sd card interface with <= 2gb and sector size of 1
word (2 bytes or 4 bytes) would be useful for all small applications.
To solidify this circuit to a particular processor destroys a lot of
its utility.

4 giga nibbles, ummm, would have made the 4004 quite a beast.

cheers jacko

Article: 138926
Subject: Re: Digital division scale
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Sat, 14 Mar 2009 22:34:45 +0000
Links: << >>  << T >>  << A >>
On Sat, 14 Mar 2009 11:05:53 -0700, 'use_real_email' wrote:

>I made a mistake the new range that i want to have is +16383 to -16384.
>The quotient from the first division (without scaling) is always 0.

So, if you left-shift the dividend by 15 places before doing the
division, you get the desired 15-bit integer in your quotient, no?
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Article: 138927
Subject: Re: Nibz processor @ <570 MAXII LEs (16 bit generic specified), 20MHz
From: Herbert Kleebauer <klee@unibwm.de>
Date: Sun, 15 Mar 2009 02:16:53 +0100
Links: << >>  << T >>  << A >>
"Antti.Lukats@googlemail.com" wrote:
> On Mar 14, 8:49 pm, rickman <gnu...@gmail.com> wrote:
> > On Mar 14, 11:11 am, Herbert Kleebauer <k...@unibwm.de> wrote:

> > > You have two operands and one result but there is only one data
> > > path to the serial memory. This means, you at least need one
> > > registers to temporary hold one of the operands and an address
> > > register to hold the address of the second operand. Mproz

> > Why do you need temporary registers?  If the memory is serial, each
> > bit can be fetched as needed. 

To fetch a bit you need the address of the bit. For two operands and
one result this makes three address registers which is more than using
a temporary register to hold one operand and only one address register
for to second operand, the result can be shifted in the temporary 
register where the operand is shifted out.


> > > As far as I remember, mproz uses about 250 two-input gates, that
> > > should fit well with 65 flip-flop's.
> >
> > How about the memory?  I expect that will be an order of magnitude
> > larger than the machine itself, even for a small program.

The size of the needed memory depends mostly on the application
and not on the CPU architecture. 



> mproz stands for minimal.. so it is minimal in terms of instructions
> and resources
> in the tradeoff of speed (8 clocks!) and program size
> 
> the machine is funny, it can do subroutine calls by patching own code
> on the fly

You don't need to patch the code (you can't patch code in ROM). You
can either use a software stack or, if the subroutine doesn't need to
be re-entrant, a fixed ram location to store the return address for
the subroutine. But indirect addressing requires self modifying
code, so you can do it only in RAM but not in ROM.

> that is self modifying code is needed, normal instructions are 6 bytes
> or 8 bytes

The jump instruction is one word (2 bytes), the add/nor instruction
4 bytes for the two address machine and 6 bytes for the three address
machine. But code density seems to be the sane for the two and three
address machine.

> if new immediate constant is needed. Also shift and rotate are very
> clumsy i guess

a left shift is simple an "add", a rotate left are three instructions:

     add   r0,r0  ; lsl r0
     br    _10    ; branch if carry not set
     add   #1,r0  ; set LSB
_10:


a rotate right is simple 15 times a rotate left.
 

> so the maximum 32K memory space would only hold say about 5K
> instructions !

The predecessor XPROZ ( http://www.bitlib.de/pub/xproz/ ) was a three
address machine with an instruction length or four 16-bit words.
A multitasking operating system with all the system utilities in a
ROM-disk still fitted in 64 kbyte ROM. The OS had drivers for a hard 
disk, floppy, serial and parallel port, keyboard interface and a 
graphics card.

Article: 138928
Subject: Re: Nibz processor @ <570 MAXII LEs (16 bit generic specified), 20MHz
From: rickman <gnuarm@gmail.com>
Date: Sat, 14 Mar 2009 20:53:04 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 14, 9:16=A0pm, Herbert Kleebauer <k...@unibwm.de> wrote:
> "Antti.Luk...@googlemail.com" wrote:
> > On Mar 14, 8:49 pm, rickman <gnu...@gmail.com> wrote:
> > > On Mar 14, 11:11 am, Herbert Kleebauer <k...@unibwm.de> wrote:
> > > > You have two operands and one result but there is only one data
> > > > path to the serial memory. This means, you at least need one
> > > > registers to temporary hold one of the operands and an address
> > > > register to hold the address of the second operand. Mproz
> > > Why do you need temporary registers? =A0If the memory is serial, each
> > > bit can be fetched as needed.
>
> To fetch a bit you need the address of the bit. For two operands and
> one result this makes three address registers which is more than using
> a temporary register to hold one operand and only one address register
> for to second operand, the result can be shifted in the temporary
> register where the operand is shifted out.

Are you saying that the mproz has all these hidden registers?  How is
that different for a serial version?  The serial version should be
able to fetch one bit of each operand and write one bit of the
result.  I don't know how the machine works in detail.  I didn't see
anything that would explain this clearly.  So I can't really say how
this could work better (smaller actually) as a bit serial machine.


> > > > As far as I remember, mproz uses about 250 two-input gates, that
> > > > should fit well with 65 flip-flop's.
>
> > > How about the memory? =A0I expect that will be an order of magnitude
> > > larger than the machine itself, even for a small program.
>
> The size of the needed memory depends mostly on the application
> and not on the CPU architecture.

That is a non-sequitur.  This machine is *very* inefficient in its use
of memory.  The memory is also a resource.  If the application does
not require any more memory than the size of the machine, it is very
unlikely that this would be smaller than a simple FSM!

I think I've lost the idea of what we are discussing here.  The
original premise was that a parallel machine can be designed with a
bit serial data path and save resources.  I supposed you can always
find some odd architecture where this is not true, but I would say it
should at least be a practical one.


> > mproz stands for minimal.. so it is minimal in terms of instructions
> > and resources
> > in the tradeoff of speed (8 clocks!) and program size
>
> > the machine is funny, it can do subroutine calls by patching own code
> > on the fly
>
> You don't need to patch the code (you can't patch code in ROM). You
> can either use a software stack or, if the subroutine doesn't need to
> be re-entrant, a fixed ram location to store the return address for
> the subroutine. But indirect addressing requires self modifying
> code, so you can do it only in RAM but not in ROM.
>
> > that is self modifying code is needed, normal instructions are 6 bytes
> > or 8 bytes
>
> The jump instruction is one word (2 bytes), the add/nor instruction
> 4 bytes for the two address machine and 6 bytes for the three address
> machine. But code density seems to be the sane for the two and three
> address machine.
>
> > if new immediate constant is needed. Also shift and rotate are very
> > clumsy i guess
>
> a left shift is simple an "add", a rotate left are three instructions:
>
> =A0 =A0 =A0add =A0 r0,r0 =A0; lsl r0
> =A0 =A0 =A0br =A0 =A0_10 =A0 =A0; branch if carry not set
> =A0 =A0 =A0add =A0 #1,r0 =A0; set LSB
> _10:
>
> a rotate right is simple 15 times a rotate left.
>
> > so the maximum 32K memory space would only hold say about 5K
> > instructions !
>
> The predecessor XPROZ (http://www.bitlib.de/pub/xproz/) was a three
> address machine with an instruction length or four 16-bit words.
> A multitasking operating system with all the system utilities in a
> ROM-disk still fitted in 64 kbyte ROM. The OS had drivers for a hard
> disk, floppy, serial and parallel port, keyboard interface and a
> graphics card.

That sounds right.  Normal CPUs can host an RTOS in around 10k to 16k
bytes, no?

Did the mproz have a purpose?  Is there anything it is especially good
at in a practical way?

Rick

Article: 138929
Subject: Re: Getting started with FPGA
From: rickman <gnuarm@gmail.com>
Date: Sat, 14 Mar 2009 22:56:22 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 14, 3:41 pm, Samuel Thomas Kerr <stk...@cs.purdue.edu> wrote:
> I'd like to design a custom microprocessor (just for learning purposes). I
> used Lattice's GAL chips with ABEL before, but quickly ran out of space.
> As such, I'd like to move over to an FPGA platform.
>
> However, I've never used FPGAs, VHDL, or Verilog before.
>
> I was wondering if someone could point me in the right direction? As far a
> development board to start with or a book on a programming language, or
> both?

What you are trying to do is a very tall task, but if it is just for
fun then go for it!  One thing that you should know is that you don't
really need hardware to work on a CPU.  It is actually better if you
do the vast majority of your work on paper... well, by paper, I mean
in a PC.  I'm an old guy, you know.

You should design your instruction set and then layout an architecture
to implement that instruction set.  Once you have an idea of what the
registers are and the data paths to connect them along with any other
functional units like ALU and such, you can start coding.  To test
your code, you should construct a test bench.  A test bench is a way
to provide the environment to run your CPU in a simulation as if it
were in the FPGA.  You can do anything in the simulation that you can
do in the FPGA with the sole limitation of the length of time.  A
simulation is slower than real time, so it can take seconds to
simulate microseconds.  I have a design that I need to simulate for 1
second to test over a full frame of data, it takes minutes to complete
that.

As to books, I can't recommend any VHDL books.  I have five and I
would not say any of them are the best, each has strengths and
weaknesses.  There are a number of good references available on the
web, including the FAQ for this newsgroup, if my memory serves me.

I would recommend that you do a search on MISC computer
architectures.  That is Minimal Instruction Set Computer.  They are
very suitable for implementation in FPGAs.  The typical RISC type CPU
will use much more resources in the FPGA and typically run slower.

Rick

Article: 138930
Subject: Re: Nibz processor @ <570 MAXII LEs (16 bit generic specified), 20MHz
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Sat, 14 Mar 2009 23:40:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 15, 5:53=A0am, rickman <gnu...@gmail.com> wrote:
> On Mar 14, 9:16=A0pm, Herbert Kleebauer <k...@unibwm.de> wrote:
>
> > "Antti.Luk...@googlemail.com" wrote:
> > > On Mar 14, 8:49 pm, rickman <gnu...@gmail.com> wrote:
> > > > On Mar 14, 11:11 am, Herbert Kleebauer <k...@unibwm.de> wrote:
> > > > > You have two operands and one result but there is only one data
> > > > > path to the serial memory. This means, you at least need one
> > > > > registers to temporary hold one of the operands and an address
> > > > > register to hold the address of the second operand. Mproz
> > > > Why do you need temporary registers? =A0If the memory is serial, ea=
ch
> > > > bit can be fetched as needed.
>
> > To fetch a bit you need the address of the bit. For two operands and
> > one result this makes three address registers which is more than using
> > a temporary register to hold one operand and only one address register
> > for to second operand, the result can be shifted in the temporary
> > register where the operand is shifted out.
>
> Are you saying that the mproz has all these hidden registers? =A0How is
> that different for a serial version? =A0The serial version should be
> able to fetch one bit of each operand and write one bit of the
> result. =A0I don't know how the machine works in detail. =A0I didn't see
> anything that would explain this clearly. =A0So I can't really say how
> this could work better (smaller actually) as a bit serial machine.
>
> > > > > As far as I remember, mproz uses about 250 two-input gates, that
> > > > > should fit well with 65 flip-flop's.
>
> > > > How about the memory? =A0I expect that will be an order of magnitud=
e
> > > > larger than the machine itself, even for a small program.
>
> > The size of the needed memory depends mostly on the application
> > and not on the CPU architecture.
>
> That is a non-sequitur. =A0This machine is *very* inefficient in its use
> of memory. =A0The memory is also a resource. =A0If the application does
> not require any more memory than the size of the machine, it is very
> unlikely that this would be smaller than a simple FSM!
>
> I think I've lost the idea of what we are discussing here. =A0The
> original premise was that a parallel machine can be designed with a
> bit serial data path and save resources. =A0I supposed you can always
> find some odd architecture where this is not true, but I would say it
> should at least be a practical one.
>
>
>
> > > mproz stands for minimal.. so it is minimal in terms of instructions
> > > and resources
> > > in the tradeoff of speed (8 clocks!) and program size
>
> > > the machine is funny, it can do subroutine calls by patching own code
> > > on the fly
>
> > You don't need to patch the code (you can't patch code in ROM). You
> > can either use a software stack or, if the subroutine doesn't need to
> > be re-entrant, a fixed ram location to store the return address for
> > the subroutine. But indirect addressing requires self modifying
> > code, so you can do it only in RAM but not in ROM.
>
> > > that is self modifying code is needed, normal instructions are 6 byte=
s
> > > or 8 bytes
>
> > The jump instruction is one word (2 bytes), the add/nor instruction
> > 4 bytes for the two address machine and 6 bytes for the three address
> > machine. But code density seems to be the sane for the two and three
> > address machine.
>
> > > if new immediate constant is needed. Also shift and rotate are very
> > > clumsy i guess
>
> > a left shift is simple an "add", a rotate left are three instructions:
>
> > =A0 =A0 =A0add =A0 r0,r0 =A0; lsl r0
> > =A0 =A0 =A0br =A0 =A0_10 =A0 =A0; branch if carry not set
> > =A0 =A0 =A0add =A0 #1,r0 =A0; set LSB
> > _10:
>
> > a rotate right is simple 15 times a rotate left.
>
> > > so the maximum 32K memory space would only hold say about 5K
> > > instructions !
>
> > The predecessor XPROZ (http://www.bitlib.de/pub/xproz/) was a three
> > address machine with an instruction length or four 16-bit words.
> > A multitasking operating system with all the system utilities in a
> > ROM-disk still fitted in 64 kbyte ROM. The OS had drivers for a hard
> > disk, floppy, serial and parallel port, keyboard interface and a
> > graphics card.
>
> That sounds right. =A0Normal CPUs can host an RTOS in around 10k to 16k
> bytes, no?
>
> Did the mproz have a purpose? =A0Is there anything it is especially good
> at in a practical way?
>
> Rick

Rick,

there is. a practical reason to use.
that is why i did convert the ISE SCH to plain VHDL

unfortunatly my notebook HDD had a bad BOD crash
stopping on CRCDISK.SYS
(pevious notebook was replaced because of similar error!)

so i am doing backups at the moment,

but yes
mproz was developed for XC2K and was great
for that architecture, at the times when 64K
was about maximum of RAM or EEPROM
available for educational institutions

Antti









Article: 138931
Subject: Re: Getting started with FPGA
From: -jg <Jim.Granville@gmail.com>
Date: Sun, 15 Mar 2009 01:20:15 -0700 (PDT)
Links: << >>  << T >>  << A >>
 On Mar 14, 3:41 pm, Samuel Thomas Kerr <stk...@cs.purdue.edu> wrote:
 > I'd like to design a custom microprocessor (just for learning
purposes). I
 > used Lattice's GAL chips with ABEL before, but quickly ran out of
space.
 > As such, I'd like to move over to an FPGA platform.
 >
 > However, I've never used FPGAs, VHDL, or Verilog before.
 >
 > I was wondering if someone could point me in the right direction?
As far a
 > development board to start with or a book on a programming
language, or
 > both?

Starting with a clean slate is harder than taking a reference design -
so look at something
like Lattice Mico8, which is an 8 bit Open Source  SoftCPU.

http://www.latticesemi.com/products/intellectualproperty/referencedesigns/8bitmicrocontrollermico8.cfm?source=topnav

This is also in both VHDL and Verilog and i see they are up to Version
3, and include
older variants, so you can also study what they changed (and why)

Then, modify that code, to push it in the way you want, and compare
your results, with
theirs.
Also see the other threads on here, some have useful links, to other
SoftCPUs and their
trade-offs.

-jg

Article: 138932
Subject: Re: Virtex 5 LVDS
From: "maxascent" <maxascent@yahoo.co.uk>
Date: Sun, 15 Mar 2009 05:59:50 -0500
Links: << >>  << T >>  << A >>
Nathan

Do you happen to know how you enable this inverter? I have looked in a few
documents but cant find how to enable it. There is mention of it in XAPP873
so I know it is possible.

Cheers

Jon



Article: 138933
Subject: Re: Virtex 5 LVDS
From: nico@puntnl.niks (Nico Coesel)
Date: Sun, 15 Mar 2009 11:48:58 GMT
Links: << >>  << T >>  << A >>
"maxascent" <maxascent@yahoo.co.uk> wrote:

>Nathan
>
>Do you happen to know how you enable this inverter? I have looked in a few
>documents but cant find how to enable it. There is mention of it in XAPP873
>so I know it is possible.

in VHDL:
a <= not b;

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
                     "If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------

Article: 138934
Subject: inout pins use in fpga
From: denish <dinesh.twanabasu@gmail.com>
Date: Sun, 15 Mar 2009 05:42:11 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,
 I am using "inout" signal for the first time in designing I2C
communication with cmos sensor module.I have completed the design. The
post map simulation worked fine and  synthesized without warnings and
errors. But when I implemented the design in Spartan 3A DSP by using
pull up resistors for the pins I couldnot get the output.Suggest me
about using the "inout" pins.
Regards
Dinesh.

Article: 138935
Subject: Re: Virtex 5 LVDS
From: "maxascent" <maxascent@yahoo.co.uk>
Date: Sun, 15 Mar 2009 08:38:28 -0500
Links: << >>  << T >>  << A >>
Hi

I dont want to infer additional logic in the fpga but use the inverter
built into the IOB. I'm not sure that using that construct will work.

Jon

Article: 138936
Subject: Re: Nibz processor @ <570 MAXII LEs (16 bit generic specified), 20MHz
From: rickman <gnuarm@gmail.com>
Date: Sun, 15 Mar 2009 06:40:44 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 15, 2:40=A0am, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> On Mar 15, 5:53=A0am, rickman <gnu...@gmail.com> wrote:
>
>
>
> > On Mar 14, 9:16=A0pm, Herbert Kleebauer <k...@unibwm.de> wrote:
> > > The predecessor XPROZ (http://www.bitlib.de/pub/xproz/) was a three
> > > address machine with an instruction length or four 16-bit words.
> > > A multitasking operating system with all the system utilities in a
> > > ROM-disk still fitted in 64 kbyte ROM. The OS had drivers for a hard
> > > disk, floppy, serial and parallel port, keyboard interface and a
> > > graphics card.
>
> > That sounds right. =A0Normal CPUs can host an RTOS in around 10k to 16k
> > bytes, no?
>
> > Did the mproz have a purpose? =A0Is there anything it is especially goo=
d
> > at in a practical way?
>
> > Rick
>
> Rick,
>
> there is. a practical reason to use.
> that is why i did convert the ISE SCH to plain VHDL
>
> unfortunatly my notebook HDD had a bad BOD crash
> stopping on CRCDISK.SYS
> (pevious notebook was replaced because of similar error!)
>
> so i am doing backups at the moment,
>
> but yes
> mproz was developed for XC2K and was great
> for that architecture, at the times when 64K
> was about maximum of RAM or EEPROM
> available for educational institutions

Ok, so this is a design for a 20 year old chip family?  Why is it
interesting today other than for historical context?

Rick

Article: 138937
Subject: Re: Virtex 5 LVDS
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Sun, 15 Mar 2009 07:28:19 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 15, 3:38=A0pm, "maxascent" <maxasc...@yahoo.co.uk> wrote:
> Hi
>
> I dont want to infer additional logic in the fpga but use the inverter
> built into the IOB. I'm not sure that using that construct will work.
>
> Jon

it should.

all inverters should be pushed into the primitives if the inversion is
available
if the tools cant do this its the tools that are rotten.
should be no need todo any magic

Antti

Article: 138938
Subject: Re: Virtex 5 LVDS
From: nico@puntnl.niks (Nico Coesel)
Date: Sun, 15 Mar 2009 14:43:43 GMT
Links: << >>  << T >>  << A >>
"maxascent" <maxascent@yahoo.co.uk> wrote:

>Hi
>
>I dont want to infer additional logic in the fpga but use the inverter
>built into the IOB. I'm not sure that using that construct will work.

The synthesizer will deal with it. Just be sure the timing constraints
are properly specified so the synthesizer has no other choice than
using the inverter in the IOB. BTW, most XIlinx primitives have
inverters on their inputs.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
                     "If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------

Article: 138939
Subject: Re: speeding hough tranformation in microblaze
From: SUMAN <sumansrb@gmail.com>
Date: Sun, 15 Mar 2009 09:18:44 -0700 (PDT)
Links: << >>  << T >>  << A >>
r = x*cos(t) + y*sin(t) is the equation of the straight line where 'r'
is the length of normal to lone from origin and 't' is the angle made
by normal with x axis. My problem is that I have sets of (x,y) values
from which i have to calulate(r,t).

So, for given (x,y) i calulate r for angle -90 to +90
and count the occurance of given (r,t)
The maximum count will be (r,t) of required line so that i can
calulate equation of straight line.
I am doing this in microblaze using its Floating point unit for
multiplication. I have created lut for sin and cos in memory.
Does any one has simpler and efficient method to solve this.

Article: 138940
Subject: Well Known? Phase Accumulator Trick
From: rickman <gnuarm@gmail.com>
Date: Sun, 15 Mar 2009 12:31:01 -0700 (PDT)
Links: << >>  << T >>  << A >>
I recently read the thread started by Jonathan Bromley, titled "Is
this phase accumulator trick well-known???".  I am building a DPLL and
I will be using this technique.  I am using a FIFO to delay data by a
fixed time where the data is clocked in and out on variable rate
clocks.  The two clocks run at the same average rate, the input clock
is gapped and the output clock is generated by the PLL to match the
average of the input clock.  By "clocks" I really mean clock enable
just so we don't get into a big discussion on metastability and such.

The requirement for a fixed time delay with a variable clock means I
need to adjust the amount of data held in the FIFO as the clock speed
changes.  It seems to me like a proportional control of the PLL
feedback using the FIFO data count will do just what I am looking
for.  I did some calcs and I know exactly how much data needs to be
held at each clock rate.  So I am going to design the phase
accumulator so that the data count is used as the phase increment
value.  I have not analyzed the dynamic characteristics of this
circuit yet, but that will be next.

I just thought it was fortuitous that this discussion had come up
recently to remind me of this circuit design.  I worked with phase
accumulators and NCOs some time back, but had forgotten most of the
details.  If that thread has not been posted I may well have forgotten
the technique of setting the accumulator modulus to control the scale
of the phase increment.  Thanks!

Rick

Article: 138941
Subject: Re: Getting started with FPGA
From: Jeff Cunningham <jcc@sover.net>
Date: Sun, 15 Mar 2009 16:44:09 -0400
Links: << >>  << T >>  << A >>
www.fpga4fun.com

Article: 138942
Subject: Re: inout pins use in fpga
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sun, 15 Mar 2009 23:33:08 +0000 (UTC)
Links: << >>  << T >>  << A >>
denish <dinesh.twanabasu@gmail.com> wrote:
> I am using "inout" signal for the first time in designing I2C
> communication with cmos sensor module.I have completed the design. The
> post map simulation worked fine and  synthesized without warnings and
> errors. But when I implemented the design in Spartan 3A DSP by using
> pull up resistors for the pins I couldnot get the output.Suggest me
> about using the "inout" pins.

You can either use tristate pins, fairly easy in verilog
and I believe also in VHDL.  You can also use open drain,
which is implemented as a tristate output with the output
value permanently 1'b0 and the enable to activate the
current sink.   Also, many FPGAs have built-in pull-ups
that can be enabled.

-- glen

Article: 138943
Subject: Re: Well Known? Phase Accumulator Trick
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Mon, 16 Mar 2009 09:31:36 +0000
Links: << >>  << T >>  << A >>
On Sun, 15 Mar 2009 12:31:01 -0700 (PDT), rickman wrote:

[...]
>If that thread has not been posted I may well have forgotten
>the technique [...]

Somehow I suspect that you would have worked it all 
out for yourself, postings or no postings.  But your
point is well made.  I'm often astonished at the way
information picked up long ago turns out to be useful
in unexpected contexts (I guess that's called 
"experience"); and a little memory-jogger is usually
needed to bring it all back (I guess that's called
"forgetfulness").
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Article: 138944
Subject: Re: Send data from FPGA to PC via USB
From: Lars <noreply.larthe@gmail.com>
Date: Mon, 16 Mar 2009 04:46:46 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi all!
It might pay with a visit to Orange Tree Technologies (http://
www.orangetreetech.com). We used their ZESTSC2 as a reference design
for a system very similar to yours, and designed our own board with a
XC3V1400A instead of the original XC3V2000. We had a hitch with the
configuration and the guys at Orange Tree where very helpful in
finding the problem, (which actually turned out to be a bug in the
throtteling of the configuration clock in the Spartan3A). Only hours
after they pointed the bug out to Xilinx, a new data sheet was
published on their website. Xilinx went the "Synopsys" way and treated
it as a feature, not a bug, but Orange Tree where able to provide us
with a software workaround in about a day. Very impressive.

/Lars

P.S. Remove the obvious if you want to mail me directly. D.S.

Article: 138945
Subject: Re: Send data from FPGA to PC via USB
From: phil hays <philhays@dont.spam>
Date: Mon, 16 Mar 2009 13:57:58 GMT
Links: << >>  << T >>  << A >>
Lars wrote:

> Xilinx went the "Synopsys" way and treated it as a feature, not
> a bug,

Way off topic.

Long before both Xilinx and Synopsys, in a computer game called "advent", 
short for adventure, as file names were restricted by the operating 
system to six characters. Back in the 1970s, to be somewhat more precise. 
In the game, if you explore the cave, you will get to the tomb of the 
unknown implementer, where a hollow voice is saying: "It's not a bug, 
it's a feature".



Article: 138946
Subject: Re: Getting started with FPGA
From: John Adair <g1@enterpoint.co.uk>
Date: Mon, 16 Mar 2009 08:20:51 -0700 (PDT)
Links: << >>  << T >>  << A >>
Some useful things linked on our website http://www.enterpoint.co.uk/techitips/techitips.html.

As to boards we have lots but maybe Drigmorn1
http://www.enterpoint.co.uk/component_replacements/drigmorn1.html
would be a good starting place.

John Adair
Enterpoint Ltd.

On 14 Mar, 19:41, Samuel Thomas Kerr <stk...@cs.purdue.edu> wrote:
> I'd like to design a custom microprocessor (just for learning purposes). I
> used Lattice's GAL chips with ABEL before, but quickly ran out of space.
> As such, I'd like to move over to an FPGA platform.
>
> However, I've never used FPGAs, VHDL, or Verilog before.
>
> I was wondering if someone could point me in the right direction? As far a
> development board to start with or a book on a programming language, or
> both?
>
> Thanks!


Article: 138947
Subject: SPI controller for FPGA
From: Vesh <veshrajsharma@gmail.com>
Date: Mon, 16 Mar 2009 08:32:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,
I am using the Xilinx Spartan 3E starter kit for driving the RFM12B RF
transceiver module. I need to have an SPI controller core that can
drive this module in SPI mode. The VHDL code that I wrote is totally
okay in simulations but its not working through the FPGA board. Can
anyone help me with it? I am not being able to debug this thing. The
simulation's all well but the RF module is not transmitting any data
and I have no idea how to debug it in FPGA hardware.

Article: 138948
Subject: Re: Getting started with FPGA
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Mon, 16 Mar 2009 08:53:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 16, 5:20=A0pm, John Adair <g...@enterpoint.co.uk> wrote:
> Some useful things linked on our websitehttp://www.enterpoint.co.uk/techi=
tips/techitips.html.
>
> As to boards we have lots but maybe Drigmorn1http://www.enterpoint.co.uk/=
component_replacements/drigmorn1.html
> would be a good starting place.
>
> John Adair
> Enterpoint Ltd.
>
> On 14 Mar, 19:41, Samuel Thomas Kerr <stk...@cs.purdue.edu> wrote:
>
> > I'd like to design a custom microprocessor (just for learning purposes)=
. I
> > used Lattice's GAL chips with ABEL before, but quickly ran out of space=
.
> > As such, I'd like to move over to an FPGA platform.
>
> > However, I've never used FPGAs, VHDL, or Verilog before.
>
> > I was wondering if someone could point me in the right direction? As fa=
r a
> > development board to start with or a book on a programming language, or
> > both?
>
> > Thanks!

I was so curious...

....to checkout if John's post has some info besides advertizement
inside.

Antti




Article: 138949
Subject: Re: MIG 2.0 for DDR - Spartan3E
From: =?ISO-8859-1?Q?Jaime_Andr=E9s_Aranguren_Cardona?= <jaime.aranguren@gmail.com>
Date: Mon, 16 Mar 2009 09:18:34 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 26 Feb., 23:02, Glen Herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> gabor wrote:
>
> (snip)
>
> > For Spartan 3 MIG, which is primitive compared to the Virtex 5
> > MIG, the order of row vs. bank addressing is not important.
> > This is due to the fact that the MIG code only leaves one
> > row of one bank active at any time. =A0The column address should
> > be your low order address bits for linear addressing. =A0This
> > will prevent unnecessary row precharge / activate sequences
> > when performing linear access to memory.
>
> One that I might try is a video display that also refreshes
> the RAM. =A0That is an old trick that might still work.
>
> > Also note that
> > the least significant bits of the column address are
> > incremented inside the memory chip during a burst operation.
> > There is no carry out to the upper address bits, so when
> > starting a burst you should normally begin at a burst
> > boundary to avoid rapping back to previous addresses.
>
> I don't expect any burst operations. =A0My first system will
> be 8080 based, and I don't believe that the 8080 does bursts.
>
> > Be careful when using the MIG top level interface with
> > "linear" address. =A0It may be using the least significant
> > bits for the bank address (depends on which interface
> > typeDDR, DDR2, etc.).
>
> -- glen

Hi guys,

Going further with the thread, I want to "report" that it seems to be
working, but partially. In simulation everything goes fine, both for
writing and reading data. I generate a sequence of numbers, fill the
memory with it, and then read all the positions back, comparing with
the sequence of numbers written. If an error is found, a counter is
incremented. At the end of the read sequence, if everything goes fine,
one led should glow, if not (even a single mismatch was found, which
means the error counter is different to zero) then 6 leds glow.

I am testing my stuff on an S3E Kit. If I just run the test for a very
few rows (say 3), then most of the times the test passes, others it
does not. If I run for higher number of rows, then at all times it
fails. So, it seems to me that I am getting timing problems. Besides,
I have to add that I am not using an external 133 MHz clock to SMA
connector, I am using the onboard 50Mhz clock instead and a couple
DCMs, one for generating a 100 MHz clock and another one to generate
the 90 degree phase shifted clock.

Reviewing the implementation reports (ISE 10.1 and ISE 9.2), I see
that the signal rst_dqs_div does not meet timing (MAX_DELAY 460 ps).
Looking into the details of the UCF, I see that this signal, which for
the S3E Starter kit is implemented as a loopback, has an assigment to
pin P13. I suppose that that is needed because of packaging to IOBs,
which is one of the project options for the MIG generated project. Is
there a way to make the signal always internal and not look for a
physical pin?

The only way I have found to meet timing constraints was to remove
that constraint in the UCF (the one that assigns rst_dqs_div signal to
pin P13), but now another problem arises: when generating the
bitstream, it fails because DRC is not passed, saying that the signal
rst_dqs_div was assigned to bank3 which uses impedance controlled
buffers or has Vref requeriments, which rst_dqs_div does not meet.

How can it be got to work reliably? Even the original project
generated by MIG (ver 2.1, ver 2.3) for the S3E Kit, without
modifications, fails to meet the timing constraints for signal
rst_dqs_div, which is supposed to be a critical timing signal
necessary to get the controller working correctly.

All your comments and suggestion are very welcome.

Kind regards.



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