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 157025

Article: 157025
Subject: Re: Know any good public FPGA projects to contribute to?
From: jim.brakefield@ieee.org
Date: Wed, 3 Sep 2014 13:05:19 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Thursday, July 24, 2014 9:45:53 PM UTC-5, signaltap wrote:
> Hi all,

> Can you suggest any good FPGA projects I could contribute to?  I have som=
e free time and want to work on something challenging and interesting.  Ins=
tead of starting something myself I'm wondering where to find some cool pro=
jects that exist already that need help.

Have an experimental processor core that needs the VHDL for the control log=
ic to be written.

Jim Brakefield


Article: 157026
Subject: Re: Know any good public FPGA projects to contribute to?
From: rickman <gnuarm@gmail.com>
Date: Wed, 03 Sep 2014 17:34:11 -0400
Links: << >>  << T >>  << A >>
On 9/3/2014 4:05 PM, jim.brakefield@ieee.org wrote:
> On Thursday, July 24, 2014 9:45:53 PM UTC-5, signaltap wrote:
>> Hi all,
>
>> Can you suggest any good FPGA projects I could contribute to?  I have some free time and want to work on something challenging and interesting.  Instead of starting something myself I'm wondering where to find some cool projects that exist already that need help.
>
> Have an experimental processor core that needs the VHDL for the control logic to be written.

There are a million processor cores out there.  What is interesting 
about yours?

-- 

Rick

Article: 157027
Subject: Re: Know any good public FPGA projects to contribute to?
From: jim.brakefield@ieee.org
Date: Wed, 3 Sep 2014 15:14:46 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Wednesday, September 3, 2014 4:34:11 PM UTC-5, rickman wrote:
>=20
> > On Thursday, July 24, 2014 9:45:53 PM UTC-5, signaltap wrote:
>=20
> >> Can you suggest any good FPGA projects I could contribute to?  I have =
some free time and want to work on something challenging and interesting.  =
Instead of starting something myself I'm wondering where to find some cool =
projects that exist already that need help.
>=20
> > Have an experimental processor core that needs the VHDL for the control=
 logic to be written.
>=20
> There are a million processor cores out there.  What is interesting=20
> about yours?

Hybrid between stack, accumulator and memory oriented instruction sets.
(1 to 4 stack pointers with offset addressing, frame & thread pointers, sin=
gle block RAM)
(data size orthogonal, single to quad issue capable, fast interrupts)

Intent is that it can be used as an accumulator machine, a stack machine or=
 a C machine.  Everything except a RISC machine.  All pointer registers (in=
cluding PC) are in a LUT RAM, stacks are in the block RAM (at least in a mi=
nimal implementation).

Article: 157028
Subject: Re: Know any good public FPGA projects to contribute to?
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Wed, 03 Sep 2014 23:47:47 +0100
Links: << >>  << T >>  << A >>
On 03/09/14 23:14, jim.brakefield@ieee.org wrote:
> On Wednesday, September 3, 2014 4:34:11 PM UTC-5, rickman wrote:
>>
>>> On Thursday, July 24, 2014 9:45:53 PM UTC-5, signaltap wrote:
>>
>>>> Can you suggest any good FPGA projects I could contribute to?  I have some free time and want to work on something challenging and interesting.  Instead of starting something myself I'm wondering where to find some cool projects that exist already that need help.
>>
>>> Have an experimental processor core that needs the VHDL for the control logic to be written.
>>
>> There are a million processor cores out there.  What is interesting
>> about yours?
>
> Hybrid between stack, accumulator and memory oriented instruction sets.
> (1 to 4 stack pointers with offset addressing, frame & thread pointers, single block RAM)
> (data size orthogonal, single to quad issue capable, fast interrupts)
>
> Intent is that it can be used as an accumulator machine, a stack machine or a C machine.  Everything except a RISC machine.  All pointer registers (including PC) are in a LUT RAM, stacks are in the block RAM (at least in a minimal implementation).

To be a bit belligerent, those are all internal /features/,
not /benefits/ visible to a user of the (black-box) processor.
Certainly they are all  more-or-less useless without tool
support (e.g. compiler, debuggers).

Now if you had said that the processor used minimal power,
or had fixed execution times for all instructions (so that
the compiler/IDE could define the execution time of each
block/loop/subroutine), then that might have been of benefit
to the user of the black box.


Article: 157029
Subject: Re: Know any good public FPGA projects to contribute to?
From: jim.brakefield@ieee.org
Date: Wed, 3 Sep 2014 16:31:54 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Wednesday, September 3, 2014 5:47:47 PM UTC-5, Tom Gardner wrote:
> > On Wednesday, September 3, 2014 4:34:11 PM UTC-5, rickman wrote:
> >>> On Thursday, July 24, 2014 9:45:53 PM UTC-5, signaltap wrote:
> >>>> Can you suggest any good FPGA projects I could contribute to?  I hav=
e some free time and want to work on something challenging and interesting.=
  Instead of starting something myself I'm wondering where to find some coo=
l projects that exist already that need help.
>=20
> >>> Have an experimental processor core that needs the VHDL for the contr=
ol logic to be written.
>=20
> >> There are a million processor cores out there.  What is interesting
> >> about yours?
>=20
> > Intent is that it can be used as an accumulator machine, a stack machin=
e or a C machine.  Everything except a RISC machine.  All pointer registers=
 (including PC) are in a LUT RAM, stacks are in the block RAM (at least in =
a minimal implementation).
>=20
> To be a bit belligerent, those are all internal /features/,
> not /benefits/ visible to a user of the (black-box) processor.
> Certainly they are all  more-or-less useless without tool
> support (e.g. compiler, debuggers).
>=20
> Now if you had said that the processor used minimal power,
> or had fixed execution times for all instructions (so that
> the compiler/IDE could define the execution time of each
> block/loop/subroutine), then that might have been of benefit
> to the user of the black box.

It does have fixed execution times.  It is intended for the hard real-time =
embedded market.
Power should be minimal: Estimating 300 Spartan6 LUTs + multiplier for 16-b=
it version.

Article: 157030
Subject: Re: Know any good public FPGA projects to contribute to?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 3 Sep 2014 23:43:34 +0000 (UTC)
Links: << >>  << T >>  << A >>
Tom Gardner <spamjunk@blueyonder.co.uk> wrote:
> On 03/09/14 23:14, jim.brakefield@ieee.org wrote:

(snip)
>> Hybrid between stack, accumulator and memory oriented instruction sets.
>> (1 to 4 stack pointers with offset addressing, frame & thread 
>> pointers, single block RAM)
>> (data size orthogonal, single to quad issue capable, fast interrupts)

>> Intent is that it can be used as an accumulator machine, a 
>> stack machine or a C machine.  Everything except a RISC machine.  
>> All pointer registers (including PC) are in a LUT RAM, stacks 
>> are in the block RAM (at least in a minimal implementation).
 
> To be a bit belligerent, those are all internal /features/,
> not /benefits/ visible to a user of the (black-box) processor.
> Certainly they are all  more-or-less useless without tool
> support (e.g. compiler, debuggers).

Well, for a high-level language programmer, I suppose. 
But for assembly programmers, those are mostly still visible.

Now, we could all say that it doesn't matter, that Intel won
the world, but I might believe that there is still something
left out there, especially if the goal isn't to get rich.

Also, there might still be some room for new ideas in soft
processors. 
 
> Now if you had said that the processor used minimal power,
> or had fixed execution times for all instructions (so that
> the compiler/IDE could define the execution time of each
> block/loop/subroutine), then that might have been of benefit
> to the user of the black box.

-- glen

Article: 157031
Subject: Re: Know any good public FPGA projects to contribute to?
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Thu, 04 Sep 2014 01:27:35 +0100
Links: << >>  << T >>  << A >>
On 04/09/14 00:31, jim.brakefield@ieee.org wrote:
> On Wednesday, September 3, 2014 5:47:47 PM UTC-5, Tom Gardner wrote:
>>> On Wednesday, September 3, 2014 4:34:11 PM UTC-5, rickman wrote:
>>>>> On Thursday, July 24, 2014 9:45:53 PM UTC-5, signaltap wrote:
>>>>>> Can you suggest any good FPGA projects I could contribute to?  I have some free time and want to work on something challenging and interesting.  Instead of starting something myself I'm wondering where to find some cool projects that exist already that need help.
>>
>>>>> Have an experimental processor core that needs the VHDL for the control logic to be written.
>>
>>>> There are a million processor cores out there.  What is interesting
>>>> about yours?
>>
>>> Intent is that it can be used as an accumulator machine, a stack machine or a C machine.  Everything except a RISC machine.  All pointer registers (including PC) are in a LUT RAM, stacks are in the block RAM (at least in a minimal implementation).
>>
>> To be a bit belligerent, those are all internal /features/,
>> not /benefits/ visible to a user of the (black-box) processor.
>> Certainly they are all  more-or-less useless without tool
>> support (e.g. compiler, debuggers).
>>
>> Now if you had said that the processor used minimal power,
>> or had fixed execution times for all instructions (so that
>> the compiler/IDE could define the execution time of each
>> block/loop/subroutine), then that might have been of benefit
>> to the user of the black box.
>
> It does have fixed execution times.  It is intended for the hard real-time embedded market.
> Power should be minimal: Estimating 300 Spartan6 LUTs + multiplier for 16-bit version.

OK, that's a benefit in some situations. I wonder
how it compares to the XMOS processors, which claim the
same advantage and are commercially available at Digikey
http://www.xmos.com/

They have good tool support.

Article: 157032
Subject: Re: Know any good public FPGA projects to contribute to?
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Thu, 04 Sep 2014 01:34:18 +0100
Links: << >>  << T >>  << A >>
On 04/09/14 00:43, glen herrmannsfeldt wrote:
> Tom Gardner <spamjunk@blueyonder.co.uk> wrote:
>> On 03/09/14 23:14, jim.brakefield@ieee.org wrote:
>
> (snip)
>>> Hybrid between stack, accumulator and memory oriented instruction sets.
>>> (1 to 4 stack pointers with offset addressing, frame & thread
>>> pointers, single block RAM)
>>> (data size orthogonal, single to quad issue capable, fast interrupts)
>
>>> Intent is that it can be used as an accumulator machine, a
>>> stack machine or a C machine.  Everything except a RISC machine.
>>> All pointer registers (including PC) are in a LUT RAM, stacks
>>> are in the block RAM (at least in a minimal implementation).
>
>> To be a bit belligerent, those are all internal /features/,
>> not /benefits/ visible to a user of the (black-box) processor.
>> Certainly they are all  more-or-less useless without tool
>> support (e.g. compiler, debuggers).
>
> Well, for a high-level language programmer, I suppose.
> But for assembly programmers, those are mostly still visible.

True, but it doesn't really invalidate my point.


> Now, we could all say that it doesn't matter, that Intel won
> the world,

No, they've carved themselves out a large lucrative niche :)


> but I might believe that there is still something
> left out there,

Very definitely. But then I've worked a few miles from the
origin of other commercial processors. e.g ARM in Cambridge,
and XMOS in Bristol.


> especially if the goal isn't to get rich.

A very valid goal, but please be explicit about that
so that other people can quickly assess its viability.


> Also, there might still be some room for new ideas in soft
> processors.

Very definitely. Over the past half decade there's been
an explosion of new commercial processor families. Most
will fall by the wayside, but some will succeed.



Article: 157033
Subject: Re: Know any good public FPGA projects to contribute to?
From: rickman <gnuarm@gmail.com>
Date: Wed, 03 Sep 2014 21:42:16 -0400
Links: << >>  << T >>  << A >>
On 9/3/2014 6:14 PM, jim.brakefield@ieee.org wrote:
> On Wednesday, September 3, 2014 4:34:11 PM UTC-5, rickman wrote:
>>
>>> On Thursday, July 24, 2014 9:45:53 PM UTC-5, signaltap wrote:
>>
>>>> Can you suggest any good FPGA projects I could contribute to?  I have some free time and want to work on something challenging and interesting.  Instead of starting something myself I'm wondering where to find some cool projects that exist already that need help.
>>
>>> Have an experimental processor core that needs the VHDL for the control logic to be written.
>>
>> There are a million processor cores out there.  What is interesting
>> about yours?
>
> Hybrid between stack, accumulator and memory oriented instruction sets.
> (1 to 4 stack pointers with offset addressing, frame & thread pointers, single block RAM)
> (data size orthogonal, single to quad issue capable, fast interrupts)
>
> Intent is that it can be used as an accumulator machine, a stack machine or a C machine.  Everything except a RISC machine.  All pointer registers (including PC) are in a LUT RAM, stacks are in the block RAM (at least in a minimal implementation).

I'm not quite understanding.  First, I don't really know what an 
"accumulator" machine is other than one which has very limited 
instructions that don't let you do much other than move stuff through an 
accumulator.  Is there some advantage to an accumulator CPU?

So it is a stack machine with stack pointers into on chip memory.  You 
feel it is useful as a platform for C.  Do you have any plans to provide 
a C compiler for this?

I would find it interesting if you could compare this to the ZPU, a 32 
bit soft core designed for C which can be quite small.  I believe the 
small version fits in around 500 LUT4s.  I'm not sure how to compare 
LUT4s to the LUT6s found in the Spartan 6.  But the ZPU is quite slow 
when running C code and possibly any code.  It takes a lot of CPU cycles 
to do nearly anything.  Do you have any timing info on your design?

-- 

Rick

Article: 157034
Subject: Re: Know any good public FPGA projects to contribute to?
From: jim.brakefield@ieee.org
Date: Wed, 3 Sep 2014 19:17:17 -0700 (PDT)
Links: << >>  << T >>  << A >>

> I'm not quite understanding.  First, I don't really know what an=20
> "accumulator" machine is other than one which has very limited=20
> instructions that don't let you do much other than move stuff through an=
=20
> accumulator.  Is there some advantage to an accumulator CPU?

For me the classic accumulator machine is the CDC 1604.
Instruction addresses a memory location and result between memory and accum=
ulator is left either in the accumulator or in memory.  CDC 1604 had six in=
dex registers.

> So it is a stack machine with stack pointers into on chip memory.  You=20
> feel it is useful as a platform for C.  Do you have any plans to provide=
=20
> a C compiler for this?

The stack pointers can be used either as stack pointers or as index registe=
rs.
The 2nd operand uses a pointer + offset address.  So second operand can be =
somewhere on any of the stacks or at absolute adr, relative adr or an immed=
iate.

Would like to have a C compiler.  Probably beyond my ability.
Am comfortable with assembler.
Consider the programming model up for grabs.  E.g., this can be considered =
a research machine.

> I would find it interesting if you could compare this to the ZPU, a 32=20
> bit soft core designed for C which can be quite small.  I believe the=20
> small version fits in around 500 LUT4s.  I'm not sure how to compare=20
> LUT4s to the LUT6s found in the Spartan 6.  But the ZPU is quite slow=20
> when running C code and possibly any code.  It takes a lot of CPU cycles=
=20
> to do nearly anything.  Do you have any timing info on your design?

ZPU has a limited instruction set.  Here, have tried to put as much functio=
nality into each instruction so each instruction does the work of several R=
ISC instructions.  While keeping code density high.

Typically it takes about 1.5 4LUTs to equal a 6LUT or an Altera ALUT.
http://opencores.com/project,up_core_list,downloads  Click on family compar=
ison link.

As currently designed instructions take 2, 3 or 4 clock cycles with a weigh=
ted average of 3.25 clock cycles (branches take 2, arithmetic 4).  Am aimin=
g to get 200MHz clock frequency on a Kintex-7 part.  Straight forward to do=
uble this by executing two instructions one clock apart using dual port Blo=
ck RAM.

Article: 157035
Subject: Re: Know any good public FPGA projects to contribute to?
From: rickman <gnuarm@gmail.com>
Date: Wed, 03 Sep 2014 23:11:39 -0400
Links: << >>  << T >>  << A >>
On 9/3/2014 10:17 PM, jim.brakefield@ieee.org wrote:
>
>> I'm not quite understanding.  First, I don't really know what an
>> "accumulator" machine is other than one which has very limited
>> instructions that don't let you do much other than move stuff through an
>> accumulator.  Is there some advantage to an accumulator CPU?
>
> For me the classic accumulator machine is the CDC 1604.
> Instruction addresses a memory location and result between memory and accumulator is left either in the accumulator or in memory.  CDC 1604 had six index registers.
>
>> So it is a stack machine with stack pointers into on chip memory.  You
>> feel it is useful as a platform for C.  Do you have any plans to provide
>> a C compiler for this?
>
> The stack pointers can be used either as stack pointers or as index registers.
> The 2nd operand uses a pointer + offset address.  So second operand can be somewhere on any of the stacks or at absolute adr, relative adr or an immediate.
>
> Would like to have a C compiler.  Probably beyond my ability.
> Am comfortable with assembler.
> Consider the programming model up for grabs.  E.g., this can be considered a research machine.
>
>> I would find it interesting if you could compare this to the ZPU, a 32
>> bit soft core designed for C which can be quite small.  I believe the
>> small version fits in around 500 LUT4s.  I'm not sure how to compare
>> LUT4s to the LUT6s found in the Spartan 6.  But the ZPU is quite slow
>> when running C code and possibly any code.  It takes a lot of CPU cycles
>> to do nearly anything.  Do you have any timing info on your design?
>
> ZPU has a limited instruction set.  Here, have tried to put as much functionality into each instruction so each instruction does the work of several RISC instructions.  While keeping code density high.
>
> Typically it takes about 1.5 4LUTs to equal a 6LUT or an Altera ALUT.
> http://opencores.com/project,up_core_list,downloads  Click on family comparison link.
>
> As currently designed instructions take 2, 3 or 4 clock cycles with a weighted average of 3.25 clock cycles (branches take 2, arithmetic 4).  Am aiming to get 200MHz clock frequency on a Kintex-7 part.  Straight forward to double this by executing two instructions one clock apart using dual port Block RAM.

Ok, so you are shooting for high code density.  Have you done any 
comparisons with other machines?  Saying "each instruction does the work 
of several RISC instructions" is just shooting from the hip.

-- 

Rick

Article: 157036
Subject: Re: Know any good public FPGA projects to contribute to?
From: jim.brakefield@ieee.org
Date: Thu, 4 Sep 2014 08:17:31 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Wednesday, September 3, 2014 10:11:39 PM UTC-5, rickman wrote:
>=20
> >
>=20
> >> I'm not quite understanding.  First, I don't really know what an
>=20
> >> "accumulator" machine is other than one which has very limited
>=20
> >> instructions that don't let you do much other than move stuff through =
an
>=20
> >> accumulator.  Is there some advantage to an accumulator CPU?
>=20
> >
>=20
> > For me the classic accumulator machine is the CDC 1604.
>=20
> > Instruction addresses a memory location and result between memory and a=
ccumulator is left either in the accumulator or in memory.  CDC 1604 had si=
x index registers.
>=20
> >
>=20
> >> So it is a stack machine with stack pointers into on chip memory.  You
>=20
> >> feel it is useful as a platform for C.  Do you have any plans to provi=
de
>=20
> >> a C compiler for this?
>=20
> >
>=20
> > The stack pointers can be used either as stack pointers or as index reg=
isters.
>=20
> > The 2nd operand uses a pointer + offset address.  So second operand can=
 be somewhere on any of the stacks or at absolute adr, relative adr or an i=
mmediate.
>=20
> >
>=20
> > Would like to have a C compiler.  Probably beyond my ability.
>=20
> > Am comfortable with assembler.
>=20
> > Consider the programming model up for grabs.  E.g., this can be conside=
red a research machine.
>=20
> >
>=20
> >> I would find it interesting if you could compare this to the ZPU, a 32
>=20
> >> bit soft core designed for C which can be quite small.  I believe the
>=20
> >> small version fits in around 500 LUT4s.  I'm not sure how to compare
>=20
> >> LUT4s to the LUT6s found in the Spartan 6.  But the ZPU is quite slow
>=20
> >> when running C code and possibly any code.  It takes a lot of CPU cycl=
es
>=20
> >> to do nearly anything.  Do you have any timing info on your design?
>=20
> >
>=20
> > ZPU has a limited instruction set.  Here, have tried to put as much fun=
ctionality into each instruction so each instruction does the work of sever=
al RISC instructions.  While keeping code density high.
>=20
> >
>=20
> > Typically it takes about 1.5 4LUTs to equal a 6LUT or an Altera ALUT.
>=20
> > http://opencores.com/project,up_core_list,downloads  Click on family co=
mparison link.
>=20
> > As currently designed instructions take 2, 3 or 4 clock cycles with a w=
eighted average of 3.25 clock cycles (branches take 2, arithmetic 4).  Am a=
iming to get 200MHz clock frequency on a Kintex-7 part.  Straight forward t=
o double this by executing two instructions one clock apart using dual port=
 Block RAM.
>=20
> Ok, so you are shooting for high code density.  Have you done any=20
> comparisons with other machines?  Saying "each instruction does the work=
=20
> of several RISC instructions" is just shooting from the hip.

There are several sources of code inefficiency in the standard RISC instruc=
tion set:
A) 16-bit immediates and displacements when they are mostly under 8-bits.
B) 15-bits per instruction for register locations (3x5)
C) Load and store instructions in addition to calculation instructions
D) Separate address modification instructions
and worst of all:
E) Subroutine overhead

A thru D: Besides the normal code density advantage of non-RISC and compact=
ed RISC versus standard RISC, the architecture supports instruction byte gr=
anularity with the single byte instructions being stack instructions.  Don'=
t have any statistics.
E: The standard C model for subroutines has the effect of discouraging shor=
t subroutines.  This is where stack machines gain a big advantage. 

Article: 157037
Subject: Re: Know any good public FPGA projects to contribute to?
From: rickman <gnuarm@gmail.com>
Date: Thu, 04 Sep 2014 14:20:28 -0400
Links: << >>  << T >>  << A >>
On 9/4/2014 11:17 AM, jim.brakefield@ieee.org wrote:
> On Wednesday, September 3, 2014 10:11:39 PM UTC-5, rickman wrote:
>>
>>>
>>
>>>> I'm not quite understanding.  First, I don't really know what an
>>
>>>> "accumulator" machine is other than one which has very limited
>>
>>>> instructions that don't let you do much other than move stuff through an
>>
>>>> accumulator.  Is there some advantage to an accumulator CPU?
>>
>>>
>>
>>> For me the classic accumulator machine is the CDC 1604.
>>
>>> Instruction addresses a memory location and result between memory and accumulator is left either in the accumulator or in memory.  CDC 1604 had six index registers.
>>
>>>
>>
>>>> So it is a stack machine with stack pointers into on chip memory.  You
>>
>>>> feel it is useful as a platform for C.  Do you have any plans to provide
>>
>>>> a C compiler for this?
>>
>>>
>>
>>> The stack pointers can be used either as stack pointers or as index registers.
>>
>>> The 2nd operand uses a pointer + offset address.  So second operand can be somewhere on any of the stacks or at absolute adr, relative adr or an immediate.
>>
>>>
>>
>>> Would like to have a C compiler.  Probably beyond my ability.
>>
>>> Am comfortable with assembler.
>>
>>> Consider the programming model up for grabs.  E.g., this can be considered a research machine.
>>
>>>
>>
>>>> I would find it interesting if you could compare this to the ZPU, a 32
>>
>>>> bit soft core designed for C which can be quite small.  I believe the
>>
>>>> small version fits in around 500 LUT4s.  I'm not sure how to compare
>>
>>>> LUT4s to the LUT6s found in the Spartan 6.  But the ZPU is quite slow
>>
>>>> when running C code and possibly any code.  It takes a lot of CPU cycles
>>
>>>> to do nearly anything.  Do you have any timing info on your design?
>>
>>>
>>
>>> ZPU has a limited instruction set.  Here, have tried to put as much functionality into each instruction so each instruction does the work of several RISC instructions.  While keeping code density high.
>>
>>>
>>
>>> Typically it takes about 1.5 4LUTs to equal a 6LUT or an Altera ALUT.
>>
>>> http://opencores.com/project,up_core_list,downloads  Click on family comparison link.
>>
>>> As currently designed instructions take 2, 3 or 4 clock cycles with a weighted average of 3.25 clock cycles (branches take 2, arithmetic 4).  Am aiming to get 200MHz clock frequency on a Kintex-7 part.  Straight forward to double this by executing two instructions one clock apart using dual port Block RAM.
>>
>> Ok, so you are shooting for high code density.  Have you done any
>> comparisons with other machines?  Saying "each instruction does the work
>> of several RISC instructions" is just shooting from the hip.
>
> There are several sources of code inefficiency in the standard RISC instruction set:
> A) 16-bit immediates and displacements when they are mostly under 8-bits.
> B) 15-bits per instruction for register locations (3x5)
> C) Load and store instructions in addition to calculation instructions
> D) Separate address modification instructions
> and worst of all:
> E) Subroutine overhead
>
> A thru D: Besides the normal code density advantage of non-RISC and compacted RISC versus standard RISC, the architecture supports instruction byte granularity with the single byte instructions being stack instructions.  Don't have any statistics.
> E: The standard C model for subroutines has the effect of discouraging short subroutines.  This is where stack machines gain a big advantage.

Ok, that is compared to RISC in a subjective manner.  How about other 
ISA types?  MISC?  Other CISC designs?

I find it interesting that you refer to issues in using C while you have 
no intent to work toward having your CPU supported by a C compiler.  Is 
anything to do with C important then?

I would point out that even if you reach 200 MHz operation on an FPGA 
that will be approximately the same as running at 57 MHz if your 
instructions used a single clock cycle, not a tricky goal usually.  In 
addition that makes many aspects of the machine simpler.

-- 

Rick

Article: 157038
Subject: Re: Know any good public FPGA projects to contribute to?
From: jim.brakefield@ieee.org
Date: Thu, 4 Sep 2014 13:50:07 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Thursday, September 4, 2014 1:20:28 PM UTC-5, rickman wrote:
>=20
> > On Wednesday, September 3, 2014 10:11:39 PM UTC-5, rickman wrote:
>=20
> >>
>=20
> >>>
>=20
> >>
>=20
> >>>> I'm not quite understanding.  First, I don't really know what an
>=20
> >>
>=20
> >>>> "accumulator" machine is other than one which has very limited
>=20
> >>
>=20
> >>>> instructions that don't let you do much other than move stuff throug=
h an
>=20
> >>
>=20
> >>>> accumulator.  Is there some advantage to an accumulator CPU?
>=20
> >>
>=20
> >>>
>=20
> >>
>=20
> >>> For me the classic accumulator machine is the CDC 1604.
>=20
> >>
>=20
> >>> Instruction addresses a memory location and result between memory and=
 accumulator is left either in the accumulator or in memory.  CDC 1604 had =
six index registers.
>=20
> >>
>=20
> >>>
>=20
> >>
>=20
> >>>> So it is a stack machine with stack pointers into on chip memory.  Y=
ou
>=20
> >>
>=20
> >>>> feel it is useful as a platform for C.  Do you have any plans to pro=
vide
>=20
> >>
>=20
> >>>> a C compiler for this?
>=20
> >>
>=20
> >>>
>=20
> >>
>=20
> >>> The stack pointers can be used either as stack pointers or as index r=
egisters.
>=20
> >>
>=20
> >>> The 2nd operand uses a pointer + offset address.  So second operand c=
an be somewhere on any of the stacks or at absolute adr, relative adr or an=
 immediate.
>=20
> >>
>=20
> >>>
>=20
> >>
>=20
> >>> Would like to have a C compiler.  Probably beyond my ability.
>=20
> >>
>=20
> >>> Am comfortable with assembler.
>=20
> >>
>=20
> >>> Consider the programming model up for grabs.  E.g., this can be consi=
dered a research machine.
>=20
> >>
>=20
> >>>
>=20
> >>
>=20
> >>>> I would find it interesting if you could compare this to the ZPU, a =
32
>=20
> >>
>=20
> >>>> bit soft core designed for C which can be quite small.  I believe th=
e
>=20
> >>
>=20
> >>>> small version fits in around 500 LUT4s.  I'm not sure how to compare
>=20
> >>
>=20
> >>>> LUT4s to the LUT6s found in the Spartan 6.  But the ZPU is quite slo=
w
>=20
> >>
>=20
> >>>> when running C code and possibly any code.  It takes a lot of CPU cy=
cles
>=20
> >>
>=20
> >>>> to do nearly anything.  Do you have any timing info on your design?
>=20
> >>
>=20
> >>>
>=20
> >>
>=20
> >>> ZPU has a limited instruction set.  Here, have tried to put as much f=
unctionality into each instruction so each instruction does the work of sev=
eral RISC instructions.  While keeping code density high.
>=20
> >>
>=20
> >>>
>=20
> >>
>=20
> >>> Typically it takes about 1.5 4LUTs to equal a 6LUT or an Altera ALUT.
>=20
> >>
>=20
> >>> http://opencores.com/project,up_core_list,downloads  Click on family =
comparison link.
>=20
> >>
>=20
> >>> As currently designed instructions take 2, 3 or 4 clock cycles with a=
 weighted average of 3.25 clock cycles (branches take 2, arithmetic 4).  Am=
 aiming to get 200MHz clock frequency on a Kintex-7 part.  Straight forward=
 to double this by executing two instructions one clock apart using dual po=
rt Block RAM.
>=20
> >>
>=20
> >> Ok, so you are shooting for high code density.  Have you done any
>=20
> >> comparisons with other machines?  Saying "each instruction does the wo=
rk
>=20
> >> of several RISC instructions" is just shooting from the hip.
>=20
> >
>=20
> > There are several sources of code inefficiency in the standard RISC ins=
truction set:
>=20
> > A) 16-bit immediates and displacements when they are mostly under 8-bit=
s.
>=20
> > B) 15-bits per instruction for register locations (3x5)
>=20
> > C) Load and store instructions in addition to calculation instructions
>=20
> > D) Separate address modification instructions
>=20
> > and worst of all:
>=20
> > E) Subroutine overhead
>=20
> >
>=20
> > A thru D: Besides the normal code density advantage of non-RISC and com=
pacted RISC versus standard RISC, the architecture supports instruction byt=
e granularity with the single byte instructions being stack instructions.  =
Don't have any statistics.
>=20
> > E: The standard C model for subroutines has the effect of discouraging =
short subroutines.  This is where stack machines gain a big advantage.
>=20
> Ok, that is compared to RISC in a subjective manner.  How about other=20
> ISA types?  MISC?  Other CISC designs?
>=20
>=20
>=20
> I find it interesting that you refer to issues in using C while you have=
=20
> no intent to work toward having your CPU supported by a C compiler.  Is=
=20
> anything to do with C important then?

Tend to consider C as typical of using a single memory stack to hold subrou=
tine frames, parameters, result, previous frame pointer and return address.=
  However, some compilers probably manage to keep some of this in registers=
.
Original Fortran used parameter lists and globally allocated memory for non=
-recursive subroutines.  On a dual stack machine, parameters can moved to t=
he return stack to create a frame.  My intent is that the ISA support any o=
f these memory usages and others as well.
=20
> I would point out that even if you reach 200 MHz operation on an FPGA=20
> that will be approximately the same as running at 57 MHz if your=20
> instructions used a single clock cycle, not a tricky goal usually.  In=20
> addition that makes many aspects of the machine simpler.

If each instruction does twice as much as a RISC instruction and if the dua=
l issue does not increase the LUT count significantly, then will have a 200=
MHz RISC equivalent.  Without pipelining.

Also possible to use LUT RAM for the stacks and increase the execution rate=
.
For now content to go with the slower design.  Yes RISCs are simple.  Keepi=
ng all the stacks in memory and all the pointers in LUT RAM is also simple.=
  For this instruction set, address ALU is 100% busy and data ALU is 30% bu=
sy.  With dual issue one needs a second address ALU and data ALU is 60% bus=
y.

Am aiming for a low LUT count, single block RAM design.  My figure of merit=
 is instructions per second per LUT (with adjustment for word size).  Very =
easy to add a few features and double the LUT count.  There is an extensive=
 comparison of soft core processors at:=20
http://opencores.com/project,up_core_list,downloads  click on best of each =
design link

Jim Brakefield

Article: 157039
Subject: Re: Know any good public FPGA projects to contribute to?
From: rickman <gnuarm@gmail.com>
Date: Thu, 04 Sep 2014 16:58:48 -0400
Links: << >>  << T >>  << A >>
On 9/4/2014 4:50 PM, jim.brakefield@ieee.org wrote:
> On Thursday, September 4, 2014 1:20:28 PM UTC-5, rickman wrote:
>>
>>> On Wednesday, September 3, 2014 10:11:39 PM UTC-5, rickman wrote:
>>
>>>>
>>
>>>>>
>>
>>>>
>>
>>>>>> I'm not quite understanding.  First, I don't really know what an
>>
>>>>
>>
>>>>>> "accumulator" machine is other than one which has very limited
>>
>>>>
>>
>>>>>> instructions that don't let you do much other than move stuff through an
>>
>>>>
>>
>>>>>> accumulator.  Is there some advantage to an accumulator CPU?
>>
>>>>
>>
>>>>>
>>
>>>>
>>
>>>>> For me the classic accumulator machine is the CDC 1604.
>>
>>>>
>>
>>>>> Instruction addresses a memory location and result between memory and accumulator is left either in the accumulator or in memory.  CDC 1604 had six index registers.
>>
>>>>
>>
>>>>>
>>
>>>>
>>
>>>>>> So it is a stack machine with stack pointers into on chip memory.  You
>>
>>>>
>>
>>>>>> feel it is useful as a platform for C.  Do you have any plans to provide
>>
>>>>
>>
>>>>>> a C compiler for this?
>>
>>>>
>>
>>>>>
>>
>>>>
>>
>>>>> The stack pointers can be used either as stack pointers or as index registers.
>>
>>>>
>>
>>>>> The 2nd operand uses a pointer + offset address.  So second operand can be somewhere on any of the stacks or at absolute adr, relative adr or an immediate.
>>
>>>>
>>
>>>>>
>>
>>>>
>>
>>>>> Would like to have a C compiler.  Probably beyond my ability.
>>
>>>>
>>
>>>>> Am comfortable with assembler.
>>
>>>>
>>
>>>>> Consider the programming model up for grabs.  E.g., this can be considered a research machine.
>>
>>>>
>>
>>>>>
>>
>>>>
>>
>>>>>> I would find it interesting if you could compare this to the ZPU, a 32
>>
>>>>
>>
>>>>>> bit soft core designed for C which can be quite small.  I believe the
>>
>>>>
>>
>>>>>> small version fits in around 500 LUT4s.  I'm not sure how to compare
>>
>>>>
>>
>>>>>> LUT4s to the LUT6s found in the Spartan 6.  But the ZPU is quite slow
>>
>>>>
>>
>>>>>> when running C code and possibly any code.  It takes a lot of CPU cycles
>>
>>>>
>>
>>>>>> to do nearly anything.  Do you have any timing info on your design?
>>
>>>>
>>
>>>>>
>>
>>>>
>>
>>>>> ZPU has a limited instruction set.  Here, have tried to put as much functionality into each instruction so each instruction does the work of several RISC instructions.  While keeping code density high.
>>
>>>>
>>
>>>>>
>>
>>>>
>>
>>>>> Typically it takes about 1.5 4LUTs to equal a 6LUT or an Altera ALUT.
>>
>>>>
>>
>>>>> http://opencores.com/project,up_core_list,downloads  Click on family comparison link.
>>
>>>>
>>
>>>>> As currently designed instructions take 2, 3 or 4 clock cycles with a weighted average of 3.25 clock cycles (branches take 2, arithmetic 4).  Am aiming to get 200MHz clock frequency on a Kintex-7 part.  Straight forward to double this by executing two instructions one clock apart using dual port Block RAM.
>>
>>>>
>>
>>>> Ok, so you are shooting for high code density.  Have you done any
>>
>>>> comparisons with other machines?  Saying "each instruction does the work
>>
>>>> of several RISC instructions" is just shooting from the hip.
>>
>>>
>>
>>> There are several sources of code inefficiency in the standard RISC instruction set:
>>
>>> A) 16-bit immediates and displacements when they are mostly under 8-bits.
>>
>>> B) 15-bits per instruction for register locations (3x5)
>>
>>> C) Load and store instructions in addition to calculation instructions
>>
>>> D) Separate address modification instructions
>>
>>> and worst of all:
>>
>>> E) Subroutine overhead
>>
>>>
>>
>>> A thru D: Besides the normal code density advantage of non-RISC and compacted RISC versus standard RISC, the architecture supports instruction byte granularity with the single byte instructions being stack instructions.  Don't have any statistics.
>>
>>> E: The standard C model for subroutines has the effect of discouraging short subroutines.  This is where stack machines gain a big advantage.
>>
>> Ok, that is compared to RISC in a subjective manner.  How about other
>> ISA types?  MISC?  Other CISC designs?
>>
>>
>>
>> I find it interesting that you refer to issues in using C while you have
>> no intent to work toward having your CPU supported by a C compiler.  Is
>> anything to do with C important then?
>
> Tend to consider C as typical of using a single memory stack to hold subroutine frames, parameters, result, previous frame pointer and return address.  However, some compilers probably manage to keep some of this in registers..
> Original Fortran used parameter lists and globally allocated memory for non-recursive subroutines.  On a dual stack machine, parameters can moved to the return stack to create a frame.  My intent is that the ISA support any of these memory usages and others as well.
>
>> I would point out that even if you reach 200 MHz operation on an FPGA
>> that will be approximately the same as running at 57 MHz if your
>> instructions used a single clock cycle, not a tricky goal usually.  In
>> addition that makes many aspects of the machine simpler.
>
> If each instruction does twice as much as a RISC instruction and if the dual issue does not increase the LUT count significantly, then will have a 200MHz RISC equivalent.  Without pipelining.
>
> Also possible to use LUT RAM for the stacks and increase the execution rate..
> For now content to go with the slower design.  Yes RISCs are simple.  Keeping all the stacks in memory and all the pointers in LUT RAM is also simple.  For this instruction set, address ALU is 100% busy and data ALU is 30% busy.  With dual issue one needs a second address ALU and data ALU is 60% busy.
>
> Am aiming for a low LUT count, single block RAM design.  My figure of merit is instructions per second per LUT (with adjustment for word size).  Very easy to add a few features and double the LUT count.  There is an extensive comparison of soft core processors at:
> http://opencores.com/project,up_core_list,downloads  click on best of each design link
>
> Jim Brakefield
>

Ok, let us know how it shakes out.

-- 

Rick

Article: 157040
Subject: Re: Know any good public FPGA projects to contribute to?
From: David Brown <david.brown@hesbynett.no>
Date: Fri, 05 Sep 2014 09:20:13 +0200
Links: << >>  << T >>  << A >>
On 04/09/14 22:50, jim.brakefield@ieee.org wrote:
> On Thursday, September 4, 2014 1:20:28 PM UTC-5, rickman wrote:
>> 

<snip and reformat - Google groups really is a /terrible/ news client>

>> 
>> I find it interesting that you refer to issues in using C while you
>> have no intent to work toward having your CPU supported by a C
>> compiler.  Is anything to do with C important then?
> 
> Tend to consider C as typical of using a single memory stack to hold
> subroutine frames, parameters, result, previous frame pointer and
> return address.  However, some compilers probably manage to keep some
> of this in registers. Original Fortran used parameter lists and
> globally allocated memory for non-recursive subroutines.  On a dual
> stack machine, parameters can moved to the return stack to create a
> frame.  My intent is that the ISA support any of these memory usages
> and others as well.

There is no requirement to have a stack for C - the standards don't even
mention the word.  And there are C implementations for machines that
have little or no stack (perhaps just a short hardware return stack).
But the most common arrangement is a single stack for frames,
parameters, and return addresses, with passed data and local variables
in registers where possible and on the stack when necessary.

The key reason for having a single stack is not processor efficiency,
but for simplicity of memory management.  Starting from low memory, you
have program code, then statically allocated data, and then the heap
(for dynamic memory) grows up into free space.  The stack starts at the
top of memory and grows downwards, until it hits the heap and the system
crashes.

If you are happy with a segmented memory, then it may be more efficient
to have multiple stacks for different purposes.  This is particularly
true if the hardware can access the stacks simultaneously.

There is quite a bit of information available on the net for multiple
stack systems.  Many target Forth rather than C, as Forth is a highly
stack-oriented language.

> 
>> I would point out that even if you reach 200 MHz operation on an
>> FPGA that will be approximately the same as running at 57 MHz if
>> your instructions used a single clock cycle, not a tricky goal
>> usually.  In addition that makes many aspects of the machine
>> simpler.
> 
> If each instruction does twice as much as a RISC instruction and if
> the dual issue does not increase the LUT count significantly, then
> will have a 200MHz RISC equivalent.  Without pipelining.

Superscaling (handling multiple instructions simultaneously) is usually
considered much more advanced and complex to implement than pipelining,
which has been common on cpu cores for decades.

> 
> Also possible to use LUT RAM for the stacks and increase the
> execution rate. For now content to go with the slower design.  Yes
> RISCs are simple.  Keeping all the stacks in memory and all the
> pointers in LUT RAM is also simple.  For this instruction set,
> address ALU is 100% busy and data ALU is 30% busy.  With dual issue
> one needs a second address ALU and data ALU is 60% busy.
> 
> Am aiming for a low LUT count, single block RAM design.  My figure of
> merit is instructions per second per LUT (with adjustment for word
> size).  Very easy to add a few features and double the LUT count.
> There is an extensive comparison of soft core processors at: 
> http://opencores.com/project,up_core_list,downloads  click on best of
> each design link
> 
> Jim Brakefield
> 


Article: 157041
Subject: Re: Know any good public FPGA projects to contribute to?
From: acd <acd4usenet@lycos.de>
Date: Fri, 5 Sep 2014 02:43:56 -0700 (PDT)
Links: << >>  << T >>  << A >>
Am Freitag, 25. Juli 2014 04:45:53 UTC+2 schrieb signaltap:
> Hi all,
>=20
>=20
>=20
> Can you suggest any good FPGA projects I could contribute to?  I have som=
e free time and want to work on something challenging and interesting.  Ins=
tead of starting something myself I'm wondering where to find some cool pro=
jects that exist already that need help.

What about NetFPGA.org?

Andreas

Article: 157042
Subject: Re: Know any good public FPGA projects to contribute to?
From: jim.brakefield@ieee.org
Date: Fri, 5 Sep 2014 07:56:02 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Friday, September 5, 2014 2:20:13 AM UTC-5, David Brown wrote:
>=20
> > On Thursday, September 4, 2014 1:20:28 PM UTC-5, rickman wrote:
>=20
> >> I find it interesting that you refer to issues in using C while you
> >> have no intent to work toward having your CPU supported by a C
> >> compiler.  Is anything to do with C important then?
>=20
> > Tend to consider C as typical of using a single memory stack to hold
> > subroutine frames, parameters, result, previous frame pointer and
> > return address.  However, some compilers probably manage to keep some
> > of this in registers. Original Fortran used parameter lists and
> > globally allocated memory for non-recursive subroutines.  On a dual
> > stack machine, parameters can moved to the return stack to create a
> > frame.  My intent is that the ISA support any of these memory usages
> > and others as well.
>=20
> There is no requirement to have a stack for C - the standards don't even
> mention the word.  And there are C implementations for machines that
> have little or no stack (perhaps just a short hardware return stack).

IMHO: There seems to be a dichotomy between embedded and GP computing.  GP =
programming frowns on using global memory whereas on an embedded chip it is=
 usually very fast.  If a subroutine is not recursive nor re-entrant, or ev=
en if it has limited recursion (typical for embedded software) one can layo=
ut the "stack frame" in global memory, one area for each subroutine (not as=
 memory efficient as a stack).
=20
>=20
> >> I would point out that even if you reach 200 MHz operation on an
> >> FPGA that will be approximately the same as running at 57 MHz if
> >> your instructions used a single clock cycle, not a tricky goal
> >> usually.  In addition that makes many aspects of the machine
> >> simpler.
>=20
> > If each instruction does twice as much as a RISC instruction and if
> > the dual issue does not increase the LUT count significantly, then
> > will have a 200MHz RISC equivalent.  Without pipelining.
>=20
> Superscaling (handling multiple instructions simultaneously) is usually
> considered much more advanced and complex to implement than pipelining,
> which has been common on cpu cores for decades.

There are some tricks that make superscaling simple in this situation.  Rem=
ember way back when there were three address computers.  This machine takes=
 one memory cycle for each operand and one cycle for the result and fetches=
 the next instruction while doing the data computation.  Block RAM is dual =
ported so two instructions can run side by side, one on each port.  They ar=
e staggered to avoid a conflict over the data ALU and to let the 2nd instru=
ction use the condition code results from the 1st.  There is a version of t=
he instruction encoding that uses either two 16-bit instructions or one 32-=
bit instruction per 32-bit word.  One could have the compiler to make sure =
the two 16-bit instructions can be properly executed side by side, insertin=
g a NOP if necessary.  One reason for four stacks is to make quad issue tec=
hnically possible, again with the help of the compiler.

Jim Brakefield

Article: 157043
Subject: Re: Know any good public FPGA projects to contribute to?
From: "pini_kr" <93490@embeddedrelated>
Date: Sat, 13 Sep 2014 04:04:01 -0500
Links: << >>  << T >>  << A >>
>Hi all,
>
>Can you suggest any good FPGA projects I could contribute to?  I have some
=
>free time and want to work on something challenging and interesting. 
Inste=
>ad of starting something myself I'm wondering where to find some cool
proje=
>cts that exist already that need help.
>
>Thanks!
>

This project implements the lower layers of a standard TCP/IP stack based
on a free code from University of Queensland: IP stack
My first steps to understand the project, after reading the documents are:
http://bknpk.ddns.net/my_web/IP_STACK/start_1.html	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 157044
Subject: Re: VHDL gate level from Xilinx XST
From: "pini_kr" <93490@embeddedrelated>
Date: Sat, 13 Sep 2014 04:17:14 -0500
Links: << >>  << T >>  << A >>
>Hi all,
>
>I need to generate a part of my VHDL project as a VHDL gate level IP, in 
>the goal to protect my generic IP core.
>
>In fact, I want to protect my own PCI core before delivering the complet 
>VHDL project.
>
>My question:
>Is this possible to do a VHDL gate level Netlist from XST.
>Then to remap it in my VHDL project.
>Then to do a concatenated VHDL file of by project .
>Then do a new synthesis and P&R with webpack from my concatenate VHDL
file.
>
>If yes, how is the best way ?
>
>Regards,
>Larry
>www.amontec.com
>
>

Yes,
I did it an IP stack (TCP/IP) free project:
"The following describes the synthesis of the VHDL IP stack, using xilinx
XST.

    The synthesis is done with the free xilinx tool: Release 10.1.03 -
xst.

    The package was installed on a debian linux distribution running on a
co-linux system..."
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 157045
Subject: Re: Getting started VHDL, VHDL for Dummies, Easy Steps for FPGA experiments
From: "pini_kr" <93490@embeddedrelated>
Date: Sat, 13 Sep 2014 04:25:45 -0500
Links: << >>  << T >>  << A >>
>Dear FPGA and VHDL Experts,
>
>I am new to FPGA and VHDL. I would like to learn VHDL and start 
>experimenting FPGA. I beleive I learn faster and better by experimenting.
>What would you recommend for beginners like me to getting started with
VHDL 
>and FPGA experimentation ?
>Which SW (for WinXP and/or Fedora Linux ) for VHDL?
>Which start-up experimentation board for FPGA?
>Which URL, books etc for easy to start experiment?
>
>Many thanks for your help.
>
>Kutaj Vamor
>
>
>
>
>
>

which SW: xilinx XST on linux
Please see the following URL:
RTL VHDL, synthesis and post NGD simulation using XST and GHDL:
http://bknpk.ddns.net/my_web/IP_STACK/start_1.html

Another interesting URL:
"This project implements an IP TTL filter in hardware. If an IPV4 packet is
identified, the machine checks its TTL field..."
http://bknpk.ddns.net/my_web/SDIO/ip_ttl_filter_main.html

"...randomize the delay between packet injections to the DUT. To generate
random numbers...."
simple way to do it using VHDL only or using a c code, which called from
within VHDL, using free VHDL simulator: GHDL
http://bknpk.ddns.net/my_web/SDIO/ip_ttl_filter_d_b_packets_rand.html	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 157046
Subject: Re: VHDL comments in Vim?
From: "pini_kr" <93490@embeddedrelated>
Date: Sat, 13 Sep 2014 04:34:51 -0500
Links: << >>  << T >>  << A >>
>Hi folks,
>
>I'm getting tired of commenting large blocks of VHDL code by hand.
>
>Anyone know of any Vim scripts that can comment/un-comment a VHDL
>block?
>
>A cursory Google search brings up either nothing or way too much stuff
>to sift through depending on my search terms ("vhdl vim comment").
>
>-- Pete
>
With VIM one can easily invoke a script from within vim on entire text
(:%!perl my_scr.pl or :'a,'b!perl ...). In my site give many useful scripts
and how to use them. 
http://bknpk.ddns.net/my_web/VIM/vim_title_bar_set.html

You find this interesting: "Run a perl script from vim on a block of text,
to enumerate constants for a state machine..."
http://bknpk.ddns.net/my_web/VIM/vim_enumerate_fsm_constants.html	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 157047
Subject: Re: Good VHDL reference?
From: "pini_kr" <93490@embeddedrelated>
Date: Sat, 13 Sep 2014 04:40:00 -0500
Links: << >>  << T >>  << A >>
>It seems I have misplaced my VHDL book a long time ago and I can't
>figure out where I left it. In short: I need a new VHDL book :-(
>
>Can anyone recommend a good generic VHDL reference? I'm not looking
>for a book with a particular bias towards fpga design, asic design, or
>simulation.
>
>
>-- 
>Reply to nico@nctdevpuntnl (punt=.)
>Bedrijven en winkels vindt U op www.adresboekje.nl
>



From complex projects of VHDL IP filter to general tips of how randomize,
print an instance name are at:

http://bknpk.ddns.net/my_web/MiscellaneousHW/MiscellaneousHW.html

http://bknpk.ddns.net/my_web/SDIO/ip_ttl_filter_main.html

"While it is simple in VERILOG (%m in the display system function), in VHDL
a bit more code writing is required.
$display("dbg instance name %m at %d", $time);
An example how to print an instance name in systemc is also available on
this site...."
http://bknpk.ddns.net/my_web/MiscellaneousHW/vhdl_path_name_print.html	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 157048
Subject: Re: Free VHDL or Verilog Simulator
From: "pini_kr" <93490@embeddedrelated>
Date: Sat, 13 Sep 2014 05:03:48 -0500
Links: << >>  << T >>  << A >>
>Hi,
>
>Altera's Quartus II does not include a free simulator.  Is there 
>a free VHDL or Verilog simulator that is reasonalbly good? 
>Google shows a few but I would prefer a recommendation.
>
>Thanks,
>Gary 
>
>
>
Use GHDL for VHDL. I used it. It can also simulate a post NGD VHDL
net-list. It supports also c interface.
http://bknpk.ddns.net/my_web/IP_STACK/start_1.html

"...andom generation using c code and VHPI..."
http://bknpk.ddns.net/my_web/SDIO/ip_ttl_filter_d_b_packets_rand.html
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 157049
Subject: Re: Free VHDL or Verilog Simulator
From: "mnentwig" <24789@embeddedrelated>
Date: Sat, 13 Sep 2014 10:21:51 -0500
Links: << >>  << T >>  << A >>
>> Icarus is great.
+1. And, gtkwave, regardless of the simulator.	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com



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