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 5/27/2016 9:30 PM, Cecil Bayona wrote: > On 5/27/2016 8:27 PM, Cecil Bayona wrote: >>> >> It looks like I didn't make myself clear enough on what I was looking >> for, I was looking for books or articles on FPGA programming that >> discusses how to use the software to program the FPGA to create CPU >> features. I already own a few books and have many articles on CPU >> architecture, plus books and literature on CPU instruction sets. >> >> Is there literature,basically a primer on how to create a simple CPU in >> HDL, preferably in VHDL? >> >> The alternative is that I will need to do it on my own by looking at a >> simple example such as the J1 , ep16, or the B16 CPUs and see what they >> are doing to create the CPU hardware blocks. The J1 is a pretty simple >> CPU done in less than 250 Verilog statements, the instructions are are >> bits controlling the various hardware features with no decoding of the >> instructions.The J16 is done in VHDL using a Lattice Brevia2 so it >> should run as is, the disadvantage is that it's more complex plus it's >> created by someone who is not very experienced. All three already have a >> compiler available to write software to test them. > > Sorry it the ep16 instead of the J16 that is in VHDL and uses a Lattice > Brevia2 board. > >> >> The disadvantage to all these simple CPUs is that there is no >> documentation to the software that creates the devices so as a rank >> beginner it will be difficult to see what they are doing. I have not seen any books on this topic, but then I haven't looked. My approach is not study the architectures of various approaches to soft CPUs and adapt to suit my needs. I did some work on a MISC (minimal instruction set computer) around 2001, 2002. I found that there were others doing the same thing and we were all discovering the same issues. Our approaches differed mainly in what our priorities were. I ended up dropping further work to a large extent. I did play with some ideas a few years ago regarding an architecture that included fields in the instruction for small offsets from the stack pointer to try to combine the advantages of register and stack machines. I think it has potential for working well at the hardware level. I just don't know enough about compiler writing to program this device from a compiler. Maybe I'll get back to this again some day. In the meantime, I suggest you work with existing CPU designs to learn what they have done. No point in reinventing the wheel. The group comp.lang.forth has a few folks who have designed their own CPUs which you seem to already be aware of. However, this is a good group to discuss your issues. I would not worry about the target device. The HDL isolates you nicely from the hardware unless you wish to highly optimize the design for a particular FPGA family. The fact that some design was implemented on a Brevia2 board really doesn't matter and can also be run on a Spartan, Cyclone or Fusion. -- Rick CArticle: 158951
On Sat, 28 May 2016 10:06:47 -0400, rickman wrote: > On 5/27/2016 9:30 PM, Cecil Bayona wrote: >> On 5/27/2016 8:27 PM, Cecil Bayona wrote: >>>> >>> It looks like I didn't make myself clear enough on what I was looking >>> for, I was looking for books or articles on FPGA programming that >>> discusses how to use the software to program the FPGA to create CPU >>> features. I already own a few books and have many articles on CPU >>> architecture, plus books and literature on CPU instruction sets. >>> >>> Is there literature,basically a primer on how to create a simple CPU >>> in HDL, preferably in VHDL? >>> >>> The alternative is that I will need to do it on my own by looking at a >>> simple example such as the J1 , ep16, or the B16 CPUs and see what >>> they are doing to create the CPU hardware blocks. The J1 is a pretty >>> simple CPU done in less than 250 Verilog statements, the instructions >>> are are bits controlling the various hardware features with no >>> decoding of the instructions.The J16 is done in VHDL using a Lattice >>> Brevia2 so it should run as is, the disadvantage is that it's more >>> complex plus it's created by someone who is not very experienced. All >>> three already have a compiler available to write software to test >>> them. >> >> Sorry it the ep16 instead of the J16 that is in VHDL and uses a Lattice >> Brevia2 board. >> >> >>> The disadvantage to all these simple CPUs is that there is no >>> documentation to the software that creates the devices so as a rank >>> beginner it will be difficult to see what they are doing. > > I have not seen any books on this topic, but then I haven't looked. My > approach is not study the architectures of various approaches to soft > CPUs and adapt to suit my needs. I did some work on a MISC (minimal > instruction set computer) around 2001, 2002. I found that there were > others doing the same thing and we were all discovering the same issues. > Our approaches differed mainly in what our priorities were. > > I ended up dropping further work to a large extent. I did play with > some ideas a few years ago regarding an architecture that included > fields in the instruction for small offsets from the stack pointer to > try to combine the advantages of register and stack machines. I think > it has potential for working well at the hardware level. I just don't > know enough about compiler writing to program this device from a > compiler. Maybe I'll get back to this again some day. Ages ago I had a notion about combining the advantages of register and stack machines, which was to call the region of 16 addresses around the stack "registers", and to have the processor automagically cache them on a context switch. The idea was that the code itself wouldn't have to specify registers to save on push and pop because the processor would do it automatically. I'm pretty sure I had not yet seen, nor independently conceive, the RISC- ish push & pop of multiple registers in one instruction. -- Tim Wescott Control systems, embedded software and circuit design I'm looking for work! See my website if you're interested http://www.wescottdesign.comArticle: 158952
On 5/28/2016 9:06 AM, rickman wrote: > On 5/27/2016 9:30 PM, Cecil Bayona wrote: >>> >>> The disadvantage to all these simple CPUs is that there is no >>> documentation to the software that creates the devices so as a rank >>> beginner it will be difficult to see what they are doing. > > I have not seen any books on this topic, but then I haven't looked. My > approach is not study the architectures of various approaches to soft > CPUs and adapt to suit my needs. I did some work on a MISC (minimal > instruction set computer) around 2001, 2002. I found that there were > others doing the same thing and we were all discovering the same issues. > Our approaches differed mainly in what our priorities were. I've found a couple of YouTube videos to help me get started, I'm looking at Amazon for books on the basics of VHDL so I'm sure that I will find enough to get started, the videos made it look easy if you are familiar with hardware design. > > I ended up dropping further work to a large extent. I did play with > some ideas a few years ago regarding an architecture that included > fields in the instruction for small offsets from the stack pointer to > try to combine the advantages of register and stack machines. I think > it has potential for working well at the hardware level. I just don't > know enough about compiler writing to program this device from a > compiler. Maybe I'll get back to this again some day. > > In the meantime, I suggest you work with existing CPU designs to learn > what they have done. No point in reinventing the wheel. The group > comp.lang.forth has a few folks who have designed their own CPUs which > you seem to already be aware of. However, this is a good group to > discuss your issues. That is my plan, I mentioned several simple CPUs before that are very small, and have software available to be able to test them without re-inventing the wheel. I would get them going, try to understand then, then start making modifications, then create one from scratch, simple at first then add improvements, it will take a while but that is part of the learning process. > > I would not worry about the target device. The HDL isolates you nicely > from the hardware unless you wish to highly optimize the design for a > particular FPGA family. The fact that some design was implemented on a > Brevia2 board really doesn't matter and can also be run on a Spartan, > Cyclone or Fusion. > For most of what I'm interested in you are right, mostly simple architectures that are lean and mean with nothing fancy, memory, registers, ALU units, and multiplexers, everybody has those devices, some boards have lot's of IO devices such as VGA, external RAM, etc but for now all I need is some RAM, and a serial port which the Brevia2 already has. An exiting adventure, I should have started on this earlier but today is better than tomorrow. -- Cecil - k5nwaArticle: 158953
On Wednesday, May 25, 2016 at 8:58:21 PM UTC+3, min...@gmail.com wrote: > Hello, > my question is probably best explained on a piece of code (the snippet is= Verilog, but the question should be mostly language-agnostic) >=20 > reg memory_access; > reg[1:0] memory_access_size; >=20 > always @ (posedge clk) begin > if (clk_en && should_decode_input) begin > memory_access_size <=3D 2'bxx; // <--- >=20 > case(some_input_data) > ACTION_1: begin > memory_access <=3D 1; > memory_access_size <=3D 2'b10; > end > ACTION_2: begin > memory_access <=3D 1; > memory_access_size <=3D 2'b01; > end > ACTION_3: begin > memory_access <=3D 0; > end > endcase > end > end >=20 > (the actual scenario is a Thumb instruction decoder) >=20 > My question is about the line marked with "// <---". If I understand the = semantics correctly, including this line should make the compiler's job eas= ier, by basically saying "unless I assign a new value to memory_access_size= , do whatever with it". Thus, in the ACTION_3 case, it doesn't have to care= about preserving its previous value (which is no longer relevant), presuma= bly reducing the logic complexity. >=20 > I'm wondering whether this really is the case, in particular: > - Will this actually lead to more efficient logic realization with genera= lly available (Altera, Xilinx) tools? > - Does this introduce any caveats to be aware of? > - Would you generally consider this a good coding practice? >=20 > Thanks in advance > -M It could be dangerous for simulation because=20 memory_access_size(0) /=3D '0' will evaluate to True if memory_access_size(= 0) =3D 'U' But I use this in my testbenches assigning DataIn <=3D x"UUUUUUUU" when Dat= aInValid =3D '0'. Then I check if DataOut never has 'U' or 'X' when DataOut= Valid =3D '1'. That means that I never use data which are not Valid.Article: 158954
On 5/28/2016 1:08 PM, Cecil Bayona wrote: > On 5/28/2016 9:06 AM, rickman wrote: >> On 5/27/2016 9:30 PM, Cecil Bayona wrote: > >>>> >>>> The disadvantage to all these simple CPUs is that there is no >>>> documentation to the software that creates the devices so as a rank >>>> beginner it will be difficult to see what they are doing. >> >> I have not seen any books on this topic, but then I haven't looked. My >> approach is not study the architectures of various approaches to soft >> CPUs and adapt to suit my needs. I did some work on a MISC (minimal >> instruction set computer) around 2001, 2002. I found that there were >> others doing the same thing and we were all discovering the same issues. >> Our approaches differed mainly in what our priorities were. > > I've found a couple of YouTube videos to help me get started, I'm > looking at Amazon for books on the basics of VHDL so I'm sure that I > will find enough to get started, the videos made it look easy if you are > familiar with hardware design. I think the need for a book is a bit overrated these days. I haven't opened a VHDL book in ages. When I don't recall something or I want to learn about new features (VHDL 2008 has many) I just do a google search. You can also get plenty of help here and in c.l.vhdl. >> I ended up dropping further work to a large extent. I did play with >> some ideas a few years ago regarding an architecture that included >> fields in the instruction for small offsets from the stack pointer to >> try to combine the advantages of register and stack machines. I think >> it has potential for working well at the hardware level. I just don't >> know enough about compiler writing to program this device from a >> compiler. Maybe I'll get back to this again some day. >> >> In the meantime, I suggest you work with existing CPU designs to learn >> what they have done. No point in reinventing the wheel. The group >> comp.lang.forth has a few folks who have designed their own CPUs which >> you seem to already be aware of. However, this is a good group to >> discuss your issues. > > That is my plan, I mentioned several simple CPUs before that are very > small, and have software available to be able to test them without > re-inventing the wheel. I would get them going, try to understand then, > then start making modifications, then create one from scratch, simple at > first then add improvements, it will take a while but that is part of > the learning process. What is your end goal? The main reason I quit working on my own was that I was not finding much room for improvement other than application specific features or optimizations. The target space has been explored pretty well at this point. The J1 is a great little processor. Then there is the ZPU which doesn't come up much in Forth circles, but is a stack machine programmed in C. >> I would not worry about the target device. The HDL isolates you nicely >> from the hardware unless you wish to highly optimize the design for a >> particular FPGA family. The fact that some design was implemented on a >> Brevia2 board really doesn't matter and can also be run on a Spartan, >> Cyclone or Fusion. >> > > For most of what I'm interested in you are right, mostly simple > architectures that are lean and mean with nothing fancy, memory, > registers, ALU units, and multiplexers, everybody has those devices, > some boards have lot's of IO devices such as VGA, external RAM, etc but > for now all I need is some RAM, and a serial port which the Brevia2 > already has. > > An exiting adventure, I should have started on this earlier but today is > better than tomorrow. The workshop should have started by now. I haven't see an email from SVFIG yet. -- Rick CArticle: 158955
On 5/28/2016 1:22 PM, rickman wrote: > On 5/28/2016 1:08 PM, Cecil Bayona wrote: >> On 5/28/2016 9:06 AM, rickman wrote: >>> On 5/27/2016 9:30 PM, Cecil Bayona wrote: >> >>>>> >>>>> The disadvantage to all these simple CPUs is that there is no >>>>> documentation to the software that creates the devices so as a rank >>>>> beginner it will be difficult to see what they are doing. >>> >>> I have not seen any books on this topic, but then I haven't looked. My >>> approach is not study the architectures of various approaches to soft >>> CPUs and adapt to suit my needs. I did some work on a MISC (minimal >>> instruction set computer) around 2001, 2002. I found that there were >>> others doing the same thing and we were all discovering the same issues. >>> Our approaches differed mainly in what our priorities were. >> >> I've found a couple of YouTube videos to help me get started, I'm >> looking at Amazon for books on the basics of VHDL so I'm sure that I >> will find enough to get started, the videos made it look easy if you are >> familiar with hardware design. > > I think the need for a book is a bit overrated these days. I haven't > opened a VHDL book in ages. When I don't recall something or I want to > learn about new features (VHDL 2008 has many) I just do a google search. > > You can also get plenty of help here and in c.l.vhdl. > > >>> I ended up dropping further work to a large extent. I did play with >>> some ideas a few years ago regarding an architecture that included >>> fields in the instruction for small offsets from the stack pointer to >>> try to combine the advantages of register and stack machines. I think >>> it has potential for working well at the hardware level. I just don't >>> know enough about compiler writing to program this device from a >>> compiler. Maybe I'll get back to this again some day. >>> >>> In the meantime, I suggest you work with existing CPU designs to learn >>> what they have done. No point in reinventing the wheel. The group >>> comp.lang.forth has a few folks who have designed their own CPUs which >>> you seem to already be aware of. However, this is a good group to >>> discuss your issues. >> >> That is my plan, I mentioned several simple CPUs before that are very >> small, and have software available to be able to test them without >> re-inventing the wheel. I would get them going, try to understand then, >> then start making modifications, then create one from scratch, simple at >> first then add improvements, it will take a while but that is part of >> the learning process. > > What is your end goal? The main reason I quit working on my own was > that I was not finding much room for improvement other than application > specific features or optimizations. The target space has been explored > pretty well at this point. > > The J1 is a great little processor. Then there is the ZPU which doesn't > come up much in Forth circles, but is a stack machine programmed in C. > > >>> I would not worry about the target device. The HDL isolates you nicely >>> from the hardware unless you wish to highly optimize the design for a >>> particular FPGA family. The fact that some design was implemented on a >>> Brevia2 board really doesn't matter and can also be run on a Spartan, >>> Cyclone or Fusion. >>> >> >> For most of what I'm interested in you are right, mostly simple >> architectures that are lean and mean with nothing fancy, memory, >> registers, ALU units, and multiplexers, everybody has those devices, >> some boards have lot's of IO devices such as VGA, external RAM, etc but >> for now all I need is some RAM, and a serial port which the Brevia2 >> already has. >> >> An exiting adventure, I should have started on this earlier but today is >> better than tomorrow. > > The workshop should have started by now. I haven't see an email from > SVFIG yet. Found it. I had to search youtube for "svfig may" https://www.youtube.com/watch?v=rhgCrnF036Y -- Rick CArticle: 158956
On Wednesday, May 25, 2016 at 9:46:51 PM UTC+3, Mark Curry wrote: > In article <10bd1028-a05c-45aa-a9db-ed43392e0b14@googlegroups.com>, > <min..w@gmail.com> wrote: > >Dne st=C5=99eda 25. kv=C4=9Btna 2016 20:16:39 UTC+2 Mark Curry napsal(a)= : > >> In article <f2fbb4be-84a9-48cc-8210-1c9ef0830ea9@googlegroups.com>, > >> <min...@gmail.com> wrote: > >> >Hello, > >> >my question is probably best explained on a piece of code (the snippe= t is Verilog, but the question should be mostly language-agnostic) > >> > > >> >reg memory_access; > >> >reg[1:0] memory_access_size; > >> > > >> >always @ (posedge clk) begin > >> > if (clk_en && should_decode_input) begin > >> > memory_access_size <=3D 2'bxx; // <--- > >> > > >> > case(some_input_data) > >> > ACTION_1: begin > >> > memory_access <=3D 1; > >> > memory_access_size <=3D 2'b10; > >> > end > >> > ACTION_2: begin > >> > memory_access <=3D 1; > >> > memory_access_size <=3D 2'b01; > >> > end > >> > ACTION_3: begin > >> > memory_access <=3D 0; > >> > end > >> > endcase > >> > end > >> >end > >> > > >> >(the actual scenario is a Thumb instruction decoder) > >> > > >> >My question is about the line marked with "// <---". If I understand = the semantics correctly, including this line should make the compiler's job= easier, by basically saying > >> >"unless I assign a new value to memory_access_size, do whatever with = it". Thus, in the ACTION_3 case, it doesn't have to care about preserving i= ts previous value (which is no > >> >longer relevant), presumably reducing the logic complexity. > >> > > >> >I'm wondering whether this really is the case, in particular: > >> >- Will this actually lead to more efficient logic realization with ge= nerally available (Altera, Xilinx) tools? > >> >- Does this introduce any caveats to be aware of? > >> >- Would you generally consider this a good coding practice? > >>=20 > >> I *AGGRESSIVELY* avoid introducing Xs, and work hard to eliminate ANY = sources of=20 > >> X in my design. Goggle search term "X-optimism", and "X-pessimism". > >> Any logic optimization's going to me TINY in the grand scheme of thing= s. > >> The hazards waiting to bite you are not worth it. > >>=20 > >> I'd "eye" optimize it, by just assigning it to one of the other values > >> you've already assigned in the other qualifications. It'll likely > >> come out darn near equivalent. > >>=20 > >> Regards, > >>=20 > >> Mark > > > >Isn't that exactly the point, though? The variable at that point really = becomes undefined > > - and if any other code assumes it to be defined, it is a bug. If the X= ends up > >propagating where it shouldn't, it means there is something wrong with t= he logic. >=20 > There's finding bugs and creating the most optimal design. > The second goal is way behind the first, IMHO. I'll not introduce > X's to get a more optimal design. Ever. =20 >=20 > As a matter of fact I go extensively out of my way to avoid hidden bugs > at sometimes significant costs to Quality of Results. =20 >=20 > Xilinx likes to preach "Don't reset everything. Reset should be the > exception not the rule." My design style is exacty the opposite. > Reset everything (to avoid initialization Xs), with some exceptions. > I'm of the opinion that Xilinx is hopelessly wrong in this regard, > and is advocating wreckless guidance.=20 >=20 > As to finding bugs, your mileage may vary. I avoid introducing X's. I d= on't > think they buy me anything actually, and may hinder. Read the papers - > there's a lot out there. There's no easy answer. >=20 > Regards, >=20 > Mark They advise it for a reason. In big and complex designs big reset network w= ith high fanout dramatically decrease maximum achievable frequency. I follo= w that for a long time and I've never had any problems as long as you rese= t properly that few signals which really need it. Usually it's some sort of= Valid signal and the state of some FSMs.Article: 158957
On Wednesday, May 25, 2016 at 9:46:51 PM UTC+3, Mark Curry wrote: > Xilinx likes to preach "Don't reset everything. Reset should be the > exception not the rule." My design style is exacty the opposite. > Reset everything (to avoid initialization Xs), with some exceptions. > I'm of the opinion that Xilinx is hopelessly wrong in this regard, > and is advocating wreckless guidance.=20 They advise it for a reason. In big and complex designs big reset network w= ith high fanout dramatically decrease maximum achievable frequency. I follo= w that for a long time and I've never had any problems as long as you rese= t properly that few signals which really need it. Usually it's some sort of= Valid signal and the state of some FSMs.Article: 158958
On 5/28/2016 12:22 PM, rickman wrote: > On 5/28/2016 1:08 PM, Cecil Bayona wrote: >> I've found a couple of YouTube videos to help me get started, I'm >> looking at Amazon for books on the basics of VHDL so I'm sure that I >> will find enough to get started, the videos made it look easy if you are >> familiar with hardware design. > > I think the need for a book is a bit overrated these days. I haven't > opened a VHDL book in ages. When I don't recall something or I want to > learn about new features (VHDL 2008 has many) I just do a google search. > > You can also get plenty of help here and in c.l.vhdl. > > I bought a couple of used VHDL books on Amazon for good prices. I agree once you get going the need for the book diminishes that is why I bought used books, the Internet is a good source of information once you know the basics. >> That is my plan, I mentioned several simple CPUs before that are very >> small, and have software available to be able to test them without >> re-inventing the wheel. I would get them going, try to understand then, >> then start making modifications, then create one from scratch, simple at >> first then add improvements, it will take a while but that is part of >> the learning process. > > What is your end goal? The main reason I quit working on my own was > that I was not finding much room for improvement other than application > specific features or optimizations. The target space has been explored > pretty well at this point. > > The J1 is a great little processor. Then there is the ZPU which doesn't > come up much in Forth circles, but is a stack machine programmed in C. > > My end goal is simple, I do it for my pleasure, no vital need here other than keeping your mind active and busy. I enjoy creating things so this will go a long way to satisfy that desire without a whole lot of expenses. I will look into the ZPU, I saw some references to it but I will look into it, I have two choices to start with, the J1, and the ep16 -- Cecil - k5nwaArticle: 158959
Dne sobota 28. kv=C4=9Btna 2016 19:31:19 UTC+2 Ilya Kalistru napsal(a): > On Wednesday, May 25, 2016 at 9:46:51 PM UTC+3, Mark Curry wrote: > > Xilinx likes to preach "Don't reset everything. Reset should be the > > exception not the rule." My design style is exacty the opposite. > > Reset everything (to avoid initialization Xs), with some exceptions. > > I'm of the opinion that Xilinx is hopelessly wrong in this regard, > > and is advocating wreckless guidance.=20 >=20 > They advise it for a reason. In big and complex designs big reset network= with high fanout dramatically decrease maximum achievable frequency. I fol= low that for a long time and I've never had any problems as long as you re= set properly that few signals which really need it. Usually it's some sort = of Valid signal and the state of some FSMs. Can't this be solved by a pipelined reset? With each step you could increase the fan-out significantly.Article: 158960
On Friday, May 27, 2016 at 11:10:26 PM UTC-4, rickman wrote: > This does not directly address your stated issues, but there is a > workshop Saturday. Notable is that it will use the same starter kit you > have. I believe you can participate via the Internet. It might be > interesting to you since it is about CPU design. Here is a post I made > about this in another group. > > Dr. Ting will be leading a workshop on using a Lattice FPGA to implement > an emulation of the 8080 instruction set which will run Forth. > > http://www.meetup.com/SV-FIG/events/229926249/ > > I believe you need to be a member of Meetup to see this page. I'm not > sure but you may need to be a member of the SVFIG meetup group as well. > There is no charge to join either. Thank you for posting this information, Rick C. I've watched some of the content that's available on YouTube from the event. It's very interesting. Best regards, Rick C. HodginArticle: 158961
On 5/28/2016 6:37 PM, Rick C. Hodgin wrote: > On Friday, May 27, 2016 at 11:10:26 PM UTC-4, rickman wrote: >> This does not directly address your stated issues, but there is a >> workshop Saturday. Notable is that it will use the same starter kit you >> have. I believe you can participate via the Internet. It might be >> interesting to you since it is about CPU design. Here is a post I made >> about this in another group. >> >> Dr. Ting will be leading a workshop on using a Lattice FPGA to implement >> an emulation of the 8080 instruction set which will run Forth. >> >> http://www.meetup.com/SV-FIG/events/229926249/ >> >> I believe you need to be a member of Meetup to see this page. I'm not >> sure but you may need to be a member of the SVFIG meetup group as well. >> There is no charge to join either. > > Thank you for posting this information, Rick C. I've watched some of > the content that's available on YouTube from the event. It's very > interesting. > > Best regards, > Rick C. Hodgin > Thanks for the info, but I was aware of the workshop and bought the Brevia2 so I could participate in the workshop, I missed part of the afternoon session as an emergency cropped up but I was planning on later in the week watch the video and follow along. with the video I can stop, wind back and take my time in following along. Previous to the workshop I loaded the software and got it working, so my goal is to go over the explanations on what the different sections do. -- Cecil - k5nwaArticle: 158962
On 5/28/2016 12:22 PM, rickman wrote: >> I've found a couple of YouTube videos to help me get started, I'm >> looking at Amazon for books on the basics of VHDL so I'm sure that I >> will find enough to get started, the videos made it look easy if you are >> familiar with hardware design. > > I think the need for a book is a bit overrated these days. I haven't > opened a VHDL book in ages. When I don't recall something or I want to > learn about new features (VHDL 2008 has many) I just do a google search. > > You can also get plenty of help here and in c.l.vhdl. > > I have several book on the way that are used and cost little so between them I should have plenty of information. I also got two used books on computer architecture that look interesting for next to nothing, overall I paid $54 for 7 hard bound books, some are new, or close to new in condition. I also went through my bookshelf and I found two books that look decent, one looks pretty nice it goes through the feature of VHDL on their use, "VHDL Made Easy". The second one is "HDL Chip Design" and it looks very useful, it goes discussing various hardware features and covers how to implement them in VHDL, and Verilog. Both books are brand new that I purchase on Amazon for less than $10 So it looks like I will have a decent reference library for not much. This coming week will be time to experiment. I've setup a Virtual Windows 7machine with VMware on two I7 PC's and they seem to be working fine. -- Cecil - k5nwaArticle: 158963
On 28/05/2016 17:41, Tim Wescott wrote: <snip> > I'm pretty sure I had not yet seen, nor independently conceive, the RISC- > ish push & pop of multiple registers in one instruction. Just an observation, but RISC instruction sets, and I'm largely basing my assumption on ARM, generally requires a few 'fast' instructions to do anything useful. If you want a single stack or pop of multiple instructions, then you would probably need a CISC CPU. YMMV -- Mike Perkins Video Solutions Ltd www.videosolutions.ltd.ukArticle: 158964
On 5/28/2016 3:49 PM, minexew@gmail.com wrote: > Dne sobota 28. května 2016 19:31:19 UTC+2 Ilya Kalistru napsal(a): >> On Wednesday, May 25, 2016 at 9:46:51 PM UTC+3, Mark Curry wrote: >>> Xilinx likes to preach "Don't reset everything. Reset should be the >>> exception not the rule." My design style is exacty the opposite. >>> Reset everything (to avoid initialization Xs), with some exceptions. >>> I'm of the opinion that Xilinx is hopelessly wrong in this regard, >>> and is advocating wreckless guidance. >> >> They advise it for a reason. In big and complex designs big reset network with high fanout dramatically decrease maximum achievable frequency. I follow that for a long time and I've never had any problems as long as you reset properly that few signals which really need it. Usually it's some sort of Valid signal and the state of some FSMs. > > Can't this be solved by a pipelined reset? > With each step you could increase the fan-out significantly. The issue with a large reset is not on the leading edge, it is on the trailing edge or exit from reset. That can be mitigated by careful design so the logic does not care about the exact timing of the reset release. In other words, design your circuits as if the reset signal were asynchronous. Often separate circuits do not need to come out of reset synchronously. The circuits will however need to have multiple FFs synchronized. This can be done by including one FF to provide a synchronized reset to that circuit. In other cases it can be done by making sure the exit from the reset state only affects one FF in your circuit. As long as the circuits do not require a synchronous release from reset, the problem is much simpler to handle. -- Rick CArticle: 158965
On 5/28/2016 12:41 PM, Tim Wescott wrote: > On Sat, 28 May 2016 10:06:47 -0400, rickman wrote: >> >> I ended up dropping further work to a large extent. I did play with >> some ideas a few years ago regarding an architecture that included >> fields in the instruction for small offsets from the stack pointer to >> try to combine the advantages of register and stack machines. I think >> it has potential for working well at the hardware level. I just don't >> know enough about compiler writing to program this device from a >> compiler. Maybe I'll get back to this again some day. > > Ages ago I had a notion about combining the advantages of register and > stack machines, which was to call the region of 16 addresses around the > stack "registers", and to have the processor automagically cache them on > a context switch. The idea was that the code itself wouldn't have to > specify registers to save on push and pop because the processor would do > it automatically. > > I'm pretty sure I had not yet seen, nor independently conceive, the RISC- > ish push & pop of multiple registers in one instruction. The register stacking approach you describe is not much different from the TMS990 mini and TMS9900 micro computers. They didn't have general purpose registers on chip, rather they had a pointer into memory which defined the general registers. Subroutine calls could be done by saving the workspace pointer, status register and program counter in the new registers allowing the context switches in a very minimal amount of time. This was the BLWP instruction. It was also possible to use the simpler BL instruction which did not change the workspace pointer and use other instructions to modify the workspace pointer as if it were a stack pointer. A bit slower than desired, but workable giving not just stacks, but stack frames from registers. Of course the limitation of this approach is the speed of memory which started out not much slower than registers, but quickly became a speed burden. This has come full circle in FPGAs where internal memory is not significantly slower than registers. -- Rick CArticle: 158966
> Can't this be solved by a pipelined reset? > With each step you could increase the fan-out significantly. We could come up with a bunch of ideas how to solve this problem in different situations but it's much wiser just not to create the problem if you can.Article: 158967
On Sunday, May 29, 2016 at 7:16:51 AM UTC-5, rickman wrote: > On 5/28/2016 12:41 PM, Tim Wescott wrote: > > On Sat, 28 May 2016 10:06:47 -0400, rickman wrote: > >> > >> I ended up dropping further work to a large extent. I did play with > >> some ideas a few years ago regarding an architecture that included > >> fields in the instruction for small offsets from the stack pointer to > >> try to combine the advantages of register and stack machines. I think > >> it has potential for working well at the hardware level. I just don't > >> know enough about compiler writing to program this device from a > >> compiler. Maybe I'll get back to this again some day. > > > > Ages ago I had a notion about combining the advantages of register and > > stack machines, which was to call the region of 16 addresses around the > > stack "registers", and to have the processor automagically cache them on > > a context switch. The idea was that the code itself wouldn't have to > > specify registers to save on push and pop because the processor would do > > it automatically. > > > > I'm pretty sure I had not yet seen, nor independently conceive, the RISC- > > ish push & pop of multiple registers in one instruction. > > The register stacking approach you describe is not much different from > the TMS990 mini and TMS9900 micro computers. They didn't have general > purpose registers on chip, rather they had a pointer into memory which > defined the general registers. Subroutine calls could be done by saving > the workspace pointer, status register and program counter in the new > registers allowing the context switches in a very minimal amount of > time. This was the BLWP instruction. > > It was also possible to use the simpler BL instruction which did not > change the workspace pointer and use other instructions to modify the > workspace pointer as if it were a stack pointer. A bit slower than > desired, but workable giving not just stacks, but stack frames from > registers. > > Of course the limitation of this approach is the speed of memory which > started out not much slower than registers, but quickly became a speed > burden. This has come full circle in FPGAs where internal memory is not > significantly slower than registers. > > -- > > Rick C ]> > Ages ago I had a notion about combining the advantages of register and ]> > stack machines, which was to call the region of 16 addresses around the ]> > stack "registers", and to have the processor automagically cache them on ]> > a context switch. The idea was that the code itself wouldn't have to ]> > specify registers to save on push and pop because the processor would do ]> > it automatically. In the context of a FPGA high performance implementation (of a soft core processor), there seem to be two/three cases: 1) "small" embedded processor where stack requirements are known in advance so that LUT RAM can serve as a register file/stack(s), and the instruction processing adds offsets to two or more register pointers. Pops & pushes modify the register pointers. 2) Larger applications that need a larger stack(s). One can either spill and refill the register file from main memory, or one can use block RAM to hold the entire stack(s), main memory being more distant than the block RAM. A third approach could be to have an associate cache of the block RAM stack(s) such that cache registers "automatically" spill and refill. Not sure of how to implement this efficiently on an FPGA? Jim BrakefieldArticle: 158968
On 5/29/2016 7:07 PM, jim.brakefield@ieee.org wrote: > On Sunday, May 29, 2016 at 7:16:51 AM UTC-5, rickman wrote: >> On 5/28/2016 12:41 PM, Tim Wescott wrote: >>> On Sat, 28 May 2016 10:06:47 -0400, rickman wrote: >>>> >>>> I ended up dropping further work to a large extent. I did play with >>>> some ideas a few years ago regarding an architecture that included >>>> fields in the instruction for small offsets from the stack pointer to >>>> try to combine the advantages of register and stack machines. I think >>>> it has potential for working well at the hardware level. I just don't >>>> know enough about compiler writing to program this device from a >>>> compiler. Maybe I'll get back to this again some day. >>> >>> Ages ago I had a notion about combining the advantages of register and >>> stack machines, which was to call the region of 16 addresses around the >>> stack "registers", and to have the processor automagically cache them on >>> a context switch. The idea was that the code itself wouldn't have to >>> specify registers to save on push and pop because the processor would do >>> it automatically. >>> >>> I'm pretty sure I had not yet seen, nor independently conceive, the RISC- >>> ish push & pop of multiple registers in one instruction. >> >> The register stacking approach you describe is not much different from >> the TMS990 mini and TMS9900 micro computers. They didn't have general >> purpose registers on chip, rather they had a pointer into memory which >> defined the general registers. Subroutine calls could be done by saving >> the workspace pointer, status register and program counter in the new >> registers allowing the context switches in a very minimal amount of >> time. This was the BLWP instruction. >> >> It was also possible to use the simpler BL instruction which did not >> change the workspace pointer and use other instructions to modify the >> workspace pointer as if it were a stack pointer. A bit slower than >> desired, but workable giving not just stacks, but stack frames from >> registers. >> >> Of course the limitation of this approach is the speed of memory which >> started out not much slower than registers, but quickly became a speed >> burden. This has come full circle in FPGAs where internal memory is not >> significantly slower than registers. >> >> -- >> >> Rick C > > ]> > Ages ago I had a notion about combining the advantages of register and > ]> > stack machines, which was to call the region of 16 addresses around the > ]> > stack "registers", and to have the processor automagically cache them on > ]> > a context switch. The idea was that the code itself wouldn't have to > ]> > specify registers to save on push and pop because the processor would do > ]> > it automatically. > > In the context of a FPGA high performance implementation (of a soft core processor), there seem to be two/three cases: > > 1) "small" embedded processor where stack requirements are known in advance so that LUT RAM can serve as a register file/stack(s), and the instruction processing adds offsets to two or more register pointers. Pops & pushes modify the register pointers. > > 2) Larger applications that need a larger stack(s). One can either spill and refill the register file from main memory, or one can use block RAM to hold the entire stack(s), main memory being more distant than the block RAM. > > A third approach could be to have an associate cache of the block RAM stack(s) such that cache registers "automatically" spill and refill. Not sure of how to implement this efficiently on an FPGA? I'm not sure what you are trying to address here. "Large" applications can still be implemented on an FPGA if it is big enough. The larger FPGAs have enormous amounts of RAM on chip, as much as 10's of MBs. It would be a large application that needed more than that. Still, if you weren't using one of the really large chips you might not have enough on chip RAM for a general stack for a C programmed processor. But it would be a really small FPGA that didn't have enough RAM for a register stack. When you talk about "spilling" the stack I think we are talking two different things. If your registers are in memory, "spilling" the stack is just a matter of changing the pointer. That's what they do in the TI processor. The only thing they do wrong is to load the register pointer from a fixed address rather than using an offset to the present value. Using this approach there is no need to copy data from registers to stack. Even if it is automatic it takes a long time to do all the memory accesses. -- Rick CArticle: 158969
On Sun, 29 May 2016 10:35:19 +0100, Mike Perkins wrote: > On 28/05/2016 17:41, Tim Wescott wrote: > > <snip> > >> I'm pretty sure I had not yet seen, nor independently conceive, the >> RISC- >> ish push & pop of multiple registers in one instruction. > > Just an observation, but RISC instruction sets, and I'm largely basing > my assumption on ARM, generally requires a few 'fast' instructions to do > anything useful. > > If you want a single stack or pop of multiple instructions, then you > would probably need a CISC CPU. >From the ARM architecture v7m reference manual, POP instruction: "Pop Multiple Registers loads a subset, or possibly all, of the general- purpose registers R0-R12 and the PC or the LR from the stack" In Thumb, the instruction is 7 bits (1011110) followed by a nine-bit bitfield specifying which registers to pop. PUSH is similar. -- Tim Wescott Control systems, embedded software and circuit design I'm looking for work! See my website if you're interested http://www.wescottdesign.comArticle: 158970
On Saturday, May 28, 2016 at 7:37:10 PM UTC-4, Rick C. Hodgin wrote:
> On Friday, May 27, 2016 at 11:10:26 PM UTC-4, rickman wrote:
> > This does not directly address your stated issues, but there is a
> > workshop Saturday. Notable is that it will use the same starter kit you
> > have. I believe you can participate via the Internet. It might be
> > interesting to you since it is about CPU design. Here is a post I made
> > about this in another group.
> >
> > Dr. Ting will be leading a workshop on using a Lattice FPGA to implement
> > an emulation of the 8080 instruction set which will run Forth.
> >
> > http://www.meetup.com/SV-FIG/events/229926249/
> >
> > I believe you need to be a member of Meetup to see this page. I'm not
> > sure but you may need to be a member of the SVFIG meetup group as well.
> > There is no charge to join either.
>
> Thank you for posting this information, Rick C. I've watched some of
> the content that's available on YouTube from the event. It's very
> interesting.
I went to Lattice's website and also bought a Brevia2 development kit.
I was able to download their Diamond software and get a license.dat file,
and I found that someone from the Meetup posted Ting's project files
online:
https://github.com/DRuffer/ep8080
I have been able to get the project loaded, but I haven't gotten to the
part where it synthesizes yet. Still going through the videos:
Morning session, a lot of ISA and architecture review:
https://www.youtube.com/watch?v=rhgCrnF036Y
Afternoon session, development, design, and synthesis:
https://www.youtube.com/watch?v=vLzEFU2GvYc
DRuffer was able to get the Forth code to run as well, and he includes
his working JEDEC file:
https://github.com/DRuffer/ep8080/tree/master/ep80
Best regards,
Rick C. Hodgin
Article: 158971
On Monday, May 30, 2016 at 11:54:11 AM UTC-4, Rick C. Hodgin wrote:
> I went to Lattice's website and also bought a Brevia2 development kit.
> I was able to download their Diamond software and get a license.dat file,
> and I found that someone from the Meetup posted Ting's project files
> online:
>
> https://github.com/DRuffer/ep8080
>
> I have been able to get the project loaded, but I haven't gotten to the
> part where it synthesizes yet. Still going through the videos:
>
> Morning session, a lot of ISA and architecture review:
> https://www.youtube.com/watch?v=rhgCrnF036Y
>
> Afternoon session, development, design, and synthesis:
> https://www.youtube.com/watch?v=vLzEFU2GvYc
>
> DRuffer was able to get the Forth code to run as well, and he includes
> his working JEDEC file:
>
> https://github.com/DRuffer/ep8080/tree/master/ep80
I may be missing an obvious link, but if anybody knows where I can get
the PPT files used in these presentations, please pot a link:
ep8080 architecture morning sessions:
Feb.27.2016: https://www.youtube.com/watch?v=-DYKuBmSGaE
Mar.26.2016: https://www.youtube.com/watch?v=XO0VqKhsPQE
Apr.23.2016: https://www.youtube.com/watch?v=s9cnnPiQtn8
Thank you in advance.
Best regards,
Rick C. Hodgin
Article: 158972On Monday, May 30, 2016 at 12:03:28 PM UTC-4, Rick C. Hodgin wrote: > On Monday, May 30, 2016 at 11:54:11 AM UTC-4, Rick C. Hodgin wrote: > > I went to Lattice's website and also bought a Brevia2 development kit. > > I was able to download their Diamond software and get a license.dat file, > > and I found that someone from the Meetup posted Ting's project files > > online: > > > > https://github.com/DRuffer/ep8080 > > > > I have been able to get the project loaded, but I haven't gotten to the > > part where it synthesizes yet. Still going through the videos: > > > > Morning session, a lot of ISA and architecture review: > > https://www.youtube.com/watch?v=rhgCrnF036Y > > > > Afternoon session, development, design, and synthesis: > > https://www.youtube.com/watch?v=vLzEFU2GvYc > > > > DRuffer was able to get the Forth code to run as well, and he includes > > his working JEDEC file: > > > > https://github.com/DRuffer/ep8080/tree/master/ep80 > > I may be missing an obvious link, but if anybody knows where I can get > the PPT files used in these presentations, please pot a link: > > ep8080 architecture morning sessions: > Feb.27.2016: https://www.youtube.com/watch?v=-DYKuBmSGaE > Mar.26.2016: https://www.youtube.com/watch?v=XO0VqKhsPQE > Apr.23.2016: https://www.youtube.com/watch?v=s9cnnPiQtn8 Also, if anyone has a block diagram or logical component layout of some kind, one which shows the internal components and how they are all hooked up through this ep8080 design, please post that info as well. Best regards, Rick C. HodginArticle: 158973
On 5/30/2016 11:41 AM, Rick C. Hodgin wrote: > On Monday, May 30, 2016 at 12:03:28 PM UTC-4, Rick C. Hodgin wrote: >> On Monday, May 30, 2016 at 11:54:11 AM UTC-4, Rick C. Hodgin wrote: >>> >>> https://github.com/DRuffer/ep8080/tree/master/ep80 >> >> I may be missing an obvious link, but if anybody knows where I can get >> the PPT files used in these presentations, please pot a link: >> >> ep8080 architecture morning sessions: >> Feb.27.2016: https://www.youtube.com/watch?v=-DYKuBmSGaE >> Mar.26.2016: https://www.youtube.com/watch?v=XO0VqKhsPQE >> Apr.23.2016: https://www.youtube.com/watch?v=s9cnnPiQtn8 > > Also, if anyone has a block diagram or logical component layout of some > kind, one which shows the internal components and how they are all hooked > up through this ep8080 design, please post that info as well. > > Best regards, > Rick C. Hodgin > I would also be interested in those items, there are several nice looking soft CPUs available for use with Forth , the common thread among is lack of documentation. -- Cecil - k5nwaArticle: 158974
On 5/30/2016 1:02 PM, Cecil Bayona wrote: > On 5/30/2016 11:41 AM, Rick C. Hodgin wrote: >> On Monday, May 30, 2016 at 12:03:28 PM UTC-4, Rick C. Hodgin wrote: >>> On Monday, May 30, 2016 at 11:54:11 AM UTC-4, Rick C. Hodgin wrote: > >>>> >>>> https://github.com/DRuffer/ep8080/tree/master/ep80 >>> >>> I may be missing an obvious link, but if anybody knows where I can get >>> the PPT files used in these presentations, please pot a link: >>> >>> ep8080 architecture morning sessions: >>> Feb.27.2016: https://www.youtube.com/watch?v=-DYKuBmSGaE >>> Mar.26.2016: https://www.youtube.com/watch?v=XO0VqKhsPQE >>> Apr.23.2016: https://www.youtube.com/watch?v=s9cnnPiQtn8 >> >> Also, if anyone has a block diagram or logical component layout of some >> kind, one which shows the internal components and how they are all hooked >> up through this ep8080 design, please post that info as well. >> >> Best regards, >> Rick C. Hodgin >> > > I would also be interested in those items, there are several nice > looking soft CPUs available for use with Forth , the common thread among > is lack of documentation. The best way to learn about the structure of the ep8080 would be to draw a block diagram from the VHDL code. I looked at the code when I debugged the problem I found and it is not so complex. There are separate registers for the user accessible registers as well as the internal registers like the PSW. There is a process for the control signals enabling the registers and controlling the various other functions in the CPU such as multiplexers and carry bits, etc. There are the multiplexers and the other data path logic. To draw the block diagram, I would follow the data path from the registers backwards to the sources. I believe you will find there is a small multiplexer on the input of each register and two larger muxes controlled by the source and destination fields of the instruction opcode. I can't say much about the rest, I didn't dig in to understand it all. Once you have mapped out the data path, you can trace the control flow through the control logic to understand how the opcode is interpreted. -- Rick C
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