Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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 BrakefieldArticle: 157026
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? -- RickArticle: 157027
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
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
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
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. -- glenArticle: 157031
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
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
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? -- RickArticle: 157034
> 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
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. -- RickArticle: 157036
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
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. -- RickArticle: 157038
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 BrakefieldArticle: 157039
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. -- RickArticle: 157040
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
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? AndreasArticle: 157042
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 BrakefieldArticle: 157043
>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.comArticle: 157044
>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>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.comArticle: 157046
>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
>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>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.comArticle: 157049
>> 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:
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