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 Monday, June 24, 2013 8:30:46 AM UTC-4, Tom Gardner wrote: > Consider what happens if interrupt occurs at inopportune moment in the above sequence, and the other thread runs. You can get double or missed updates. I think you're missing the point that in my processor the threads run concurrently, not sequentially.Article: 155351
On 6/24/2013 5:20 AM, Uwe Bonnes wrote: > Guy Eschemann <Guy.Eschemann@gmail.com> wrote: >> I'd like to introduce a new FPGA discussion forum. It's called >> FPGA Exchange, and you can check it out at: http://fpga-exchange.com > >> Feel free to jump in, create new topics, or answer existing ones. > > Any reason for trying to split up the community? > Time will tell if fpga-exchange will offer new or better discussions. There is always room for a new kid, lets see if it lasts. hamiltonArticle: 155352
Eric Wallin wrote: > On Monday, June 24, 2013 8:30:46 AM UTC-4, Tom Gardner wrote: > >> Consider what happens if interrupt occurs at inopportune moment in the above sequence, and the other thread runs. You can get double or missed updates. > > I think you're missing the point that in my processor the threads run concurrently, not sequentially. Nope. That usually exacerbates problems, plus having 8-port memory (one for each thread) is not cheap! Please explain why your processor does not need test and set or compare and exchange operations. What theoretical advance have you made?Article: 155353
This is a good thread. In out system, the application software would check a version number register at boot time to make sure it was running with the right FPGA design. The problem with my manually updated version register is that I always forgot to update it until after the FPGA build and test work was done. To update the version number I had to re-run the FPGA build and, of course, the testing. Our FPGA had a PCIe interface so it must configure from an on-board flash in order to boot in time for PCIe enumeration cycles. The on-board configuration flash is readable and writeable across the PCIe bus by the Linux host. Eventually, I noticed that the Xilinx configuration bit file header contains a date and time that is automatically incremented at build time. I tried to get the software guys to just read the bit file header and parse the date and time out of there. They could have just used those fields as a unique identifier. In the end, I could never convince them to do that. I have actually, sent suggestions to Xilinx on this subject but I haven't heard of any enhancements to support an automatically updated version or date/time register in the code. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 155354
padudle <93037@embeddedrelated> wrote: > In out system, the application software would check a version number > register at boot time to make sure it was running with the right FPGA > design. The problem with my manually updated version register is that I > always forgot to update it until after the FPGA build and test work was > done. To update the version number I had to re-run the FPGA build and, of > course, the testing. If you use a version control systems, such as CVS, SVN, (and I believe also GIT) there is a way to have it automatically update a field in the file as it is checked in with the version number. You should be able to use that to make a hardware readable register with the version number in it. -- glenArticle: 155355
On Monday, June 24, 2013 9:47:28 AM UTC-4, Tom Gardner wrote: > Please explain why your processor does not need test and set or compare a= nd exchange operations. What theoretical advance have you made? I'm not exactly sure why we're having this generalized, theoretical discuss= ion when a simple reading the design document I've provided would probably = answer your questions. If it doesn't then perhaps you could tell me what I= left out, and I might include that info in the next rev. Not trying to be= gruff or anything, I'd very much like the document (and processor) to be o= n as solid a footing as possible.Article: 155356
I get a message "Unfortunately, your browser is too old to work on this Discourse forum. Please upgrade your browser." The IT Department here determine what browser I use, so I won't be contributing. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 155357
Eric Wallin wrote: > On Monday, June 24, 2013 9:47:28 AM UTC-4, Tom Gardner wrote: > >> Please explain why your processor does not need test and set or compare and exchange operations. What theoretical advance have you made? > > I'm not exactly sure why we're having this generalized, theoretical discussion when a simple reading the design document I've provided would probably answer your questions. Please point me to the section which discusses the primitive operations/attributes/properties that you have provided to enable inter-thread communication. > If it doesn't then perhaps you could tell me what I left out, and I might include that info in the next rev. Sorry, I don't have time to poorly recapitulate subjects that have been know about and solved for decades. > Not trying to be gruff or anything, I'd very much like the document (and processor) to be on as solid a footing as possible. Ditto, and I don't have time to find the flaws in your arguments. If you want people to use your processor, it might be wise to give them the information they need to have confidence in its design.Article: 155358
On 6/24/2013 11:57 AM, Eric Wallin wrote: > On Monday, June 24, 2013 9:47:28 AM UTC-4, Tom Gardner wrote: > >> Please explain why your processor does not need test and set or compare and exchange operations. What theoretical advance have you made? > > I'm not exactly sure why we're having this generalized, theoretical discussion when a simple reading the design document I've provided would probably answer your questions. If it doesn't then perhaps you could tell me what I left out, and I might include that info in the next rev. Not trying to be gruff or anything, I'd very much like the document (and processor) to be on as solid a footing as possible. Eric, I think you have explained properly how your design will deal with synchronization. I'm not sure what Tom is going on about. Clearly he doesn't understand your design. If it is of any help, Eric's design is more like 8 cores running in parallel, time sharing memory and in fact, the same processor hardware on a machine cycle basis (so no 8 ported memory required). If an interrupt occurs it doesn't cause one of the other 7 tasks to run, they are already running, it simply invokes the interrupt handler. I believe Eric is not envisioning multiple tasks on a single processor. As others have pointed out, test and set instructions are not required to support concurrency and communications. They are certainly nice to have, but are not essential. In your case they would be superfluous. -- RickArticle: 155359
rickman wrote: > On 6/24/2013 11:57 AM, Eric Wallin wrote: >> On Monday, June 24, 2013 9:47:28 AM UTC-4, Tom Gardner wrote: >> >>> Please explain why your processor does not need test and set or compare and exchange operations. What theoretical advance have you made? >> >> I'm not exactly sure why we're having this generalized, theoretical discussion when a simple reading the design document I've provided would probably answer your questions. If it doesn't then >> perhaps you could tell me what I left out, and I might include that info in the next rev. Not trying to be gruff or anything, I'd very much like the document (and processor) to be on as solid a >> footing as possible. > > Eric, I think you have explained properly how your design will deal with synchronization. I'm not sure what Tom is going on about. Clearly he doesn't understand your design. Correct. > If it is of any help, Eric's design is more like 8 cores running in parallel, time sharing memory and in fact, the same processor hardware on a machine cycle basis >(so no 8 ported memory required). Fair enough; sounds like it is in the same area as the propellor chip. Is there anything to prevent multiple cores reading/writing the same memory location in the same machine cycle? What is the result when that happens? > If an interrupt occurs it doesn't cause one of the other 7 tasks to run, they are already running, it simply invokes the interrupt handler. I believe Eric is not envisioning multiple tasks on a > single processor. Such presumptions would be useful to have in the white paper. > As others have pointed out, test and set instructions are not required to support concurrency and communications. They are certainly nice to have, but are not essential. Agreed. I'm perfectly prepared to accept alternative techniques, e.g. disable interrupts. > In your case they would be superfluous. Not proven to me. The trouble is I've seen too many hardware designs that leave the awkward problems to software - especially first efforts by small teams. And too often those problems can be very difficult to solve in software. Nowadays it is hard to find people that have sufficient experience across the whole hardware/firmware/system software spectrum to enable them to avoid such traps. I don't know whether Eric is such a person, but I'm afraid his answers have raised orange flags in my mind. As a point of reference, I had similar misgivings when I first heard about the Itanium's architecture in, IIRC, 1994. I suppressed them because the people involved were undoubtedly more skilled in the area that I, and had been working for 5 years. Much later I regrettably came to the conclusion the orange flags were too optimistic.Article: 155360
I've done this with my own makefile, but next time I'd like to try this wit= h the Synplify callback function. (If you aren't using Synplify, this prob= ably won't help in your case.) Synplify lets you write TCL callback functi= ons, for example, one that will run right before synthesis, so you could th= eoretically write a simple 3-line TCL function that would create a date sta= mp even if you're using the GUI.Article: 155361
Kevin Neilson wrote: > I've done this with my own makefile, but next time I'd like to try > this with the Synplify callback function. (If you aren't using > Synplify, this probably won't help in your case.) Synplify lets you > write TCL callback functions, for example, one that will run right > before synthesis, so you could theoretically write a simple 3-line > TCL function that would create a date stamp even if you're using the > GUI. Vivado now allows execution of pre-synthesis TCL scripts that can be used to generate e.g. a VHDL package file containing version numbers/time stamps. Unfortunately, AFAIK this currently (as of Vivado 2013.2) is not usable in this case, because Vivado will detect the source files have changed AFTER synthesis, hence it will always complain that your synthesis results are out-of date. This is a known bug and I was promised that would be fixed in 2013.1, which obviously it wasn't... So I'm sticking with my scripted flow. Greetings, SeanArticle: 155362
Tom Gardner <spamjunk@blueyonder.co.uk> wrote: (snip) > Is there anything to prevent multiple cores reading/writing the > same memory location in the same machine cycle? What is the > result when that happens? Yes. Even if the threads don't communicate with each other, they might share I/O devices which needs some communication. (sniP) > The trouble is I've seen too many hardware designs that > leave the awkward problems to software - especially first > efforts by small teams. The 8087 was originally designed to have a virtual stack, where on stack overflow an interrupt would trigger a software routine to spill some stack registers to memory, and on underflow bring them back again. But no-one tried to write the interrupt routine until the hardware was done, and it turned out that it wasn't possible. Not all the required state was available or settable. They might have fixed it in the 80287, but then they had to be compatible with the 8087. Actually, I don't know why they didn't fix it, but it still isn't fixed. -- glenArticle: 155363
glen herrmannsfeldt wrote: > Tom Gardner <spamjunk@blueyonder.co.uk> wrote: > > (snip) >> Is there anything to prevent multiple cores reading/writing the >> same memory location in the same machine cycle? What is the >> result when that happens? > > Yes. Even if the threads don't communicate with each other, they > might share I/O devices which needs some communication. > > (sniP) > >> The trouble is I've seen too many hardware designs that >> leave the awkward problems to software - especially first >> efforts by small teams. > > The 8087 was originally designed to have a virtual stack, where > on stack overflow an interrupt would trigger a software routine > to spill some stack registers to memory, and on underflow bring > them back again. But no-one tried to write the interrupt routine > until the hardware was done, and it turned out that it wasn't > possible. Not all the required state was available or settable. Oh, inaccessible state is a problem that has been repeated many times in many companies! Often to be found near to virtual memory tables, exceptions, interrupts, and debuggers - making Heisenbugs the norm not the exception :( > They might have fixed it in the 80287, but then they had to be > compatible with the 8087. Actually, I don't know why they didn't > fix it, but it still isn't fixed. I strongly suspect compatibility is the (fully justifiable) reason; it is the reason for all sorts of hardware and software cruft.Article: 155364
On Monday, June 24, 2013 12:07:23 AM UTC-4, rickman wrote: > I'm glad you can take (hopefully) constructive criticism. I was=20 > concerned when I wrote the above that it might be a bit too blunt. I apologize to everyone here, I kind of barged in and have behaved somewhat= brashly. > ... part of the utility=20 > of a design is the ease of programming efficiently. I haven't looked at= =20 > yours yet, but just picturing the four stacks makes it seem pretty=20 > simple... so far. :^)=20 Writing a conventional stack machine in an HDL isn't too daunting, but prog= ramming it afterward, for me anyway, was just too much. > I have to say I'm not crazy about the large instruction word. That is=20 > one of the appealing things about MISC to me. I work in very small=20 > FPGAs and 16 bit instructions are better avoided if possible, but that=20 > may be a red herring. What matters is how many bytes a given program=20 > uses, not how many bits are in an instruction. Yes. Opcode space obviously expands exponentially with bit count, so one c= an get a lot more with a small size increase. I think a 32 bit opcode is p= ushing it for a small FPGA implementation, but a 16 bit opcode gives one a = couple of small operand indices, and some reasonably sized immediate instru= ctions (data, conditional jumps, shifts, add) that I find I'm using quite a= bit during the testing and verification phase. Data plus operation in a s= ingle opcode is hard to beat for efficiency but it has to earn it's keep in= the expanded opcode space. With the operand indices you get a free copy/m= ove with most single operand operations which is another efficiency. > I am supposed to present to the SVFIG and I think your design would be a= =20 > very interesting part of the presentation unless you think you would=20 > rather present yourself. I'm sure they would like to hear about it and= =20 > they likely would be interested in your opinions on MISC. I know I am. I'm on the other coast so I most likely can't attend, but I would be most h= onored if you were to present it to SVFIG.Article: 155365
On Monday, June 24, 2013 12:56:05 PM UTC-4, Tom Gardner wrote: > The trouble is I've seen too many hardware designs that > leave the awkward problems to software - especially first > efforts by small teams. I know what you mean. Maybe I'm too picky, or perhaps too rigid to conform= to other's coding styles, but 90% of the HDL code I've encountered both vo= cationally and avocationally has been quite poor. I tend to rewrite every= thing, including my slightly older code if I'm using it again, because my s= tyle keeps evolving, and it never hurts to take another look at things or a= t least give them some more polish. > And too often those problems can be very difficult to solve > in software. Nowadays it is hard to find people that have > sufficient experience across the whole hardware/firmware/system > software spectrum to enable them to avoid such traps. > > I don't know whether Eric is such a person, but I'm afraid > his answers have raised orange flags in my mind. Processors aren't my main thing, but I do have need of them in my main thin= g so I've been quite interested in them for ~15 years now. My EE graduate = adviser was a professor of computer engineering and I took a couple of his = courses. I own and have read the two Hennesey & Patterson (sp?) texts, tho= ugh I must admit my eyes glazed over when TLBs and pipeline hazards were be= ing discussed. Discovering stack machines was a transforming experience for me, showing th= at it was possible to have much simpler and tractable HW underlying it all.= But it's hard to beat indexed registers. This hybrid is something of a m= iddle ground, and so far I'm not finding it too revolting to program by han= d - then again it might be something only a mother can love.Article: 155366
Eric Wallin wrote: > On Monday, June 24, 2013 12:56:05 PM UTC-4, Tom Gardner wrote: > >> The trouble is I've seen too many hardware designs that >> leave the awkward problems to software - especially first >> efforts by small teams. > > I know what you mean. Maybe I'm too picky, or perhaps too rigid to conform to other's coding styles, but 90% of the HDL code I've encountered both vocationally and avocationally has been quite poor. I tend to rewrite everything, including my slightly older code if I'm using it again, because my style keeps evolving, and it never hurts to take another look at things or at least give them some more polish. > >> And too often those problems can be very difficult to solve >> in software. Nowadays it is hard to find people that have >> sufficient experience across the whole hardware/firmware/system >> software spectrum to enable them to avoid such traps. >> >> I don't know whether Eric is such a person, but I'm afraid >> his answers have raised orange flags in my mind. > > Processors aren't my main thing, but I do have need of them in my main thing so I've been quite interested in them for ~15 years now. My EE graduate adviser was a professor of computer engineering and I took a couple of his courses. I own and have read the two Hennesey & Patterson (sp?) texts, though I must admit my eyes glazed over when TLBs and pipeline hazards were being discussed. > > Discovering stack machines was a transforming experience for me, showing that it was possible to have much simpler and tractable HW underlying it all. But it's hard to beat indexed registers. This hybrid is something of a middle ground, and so far I'm not finding it too revolting to program by hand - then again it might be something only a mother can love. Doing something "just because I want to" is an _excellent_ reason. For me probably the next such project will be to make a cheapskate 1GS/s oscilloscope & TDR. But there's a heck of a learning curve w.r.t. FPGA clocking, i/o structures, floorplanning and dev kits nowadays! Whenever I've come across people that say "if you have problem X then my product will solve it provided Y applies", I give them more credence if they also say "but my product doesn't do Z, you have to do that some other way". I'm sure you've had similar experiences.Article: 155367
On Thursday, June 20, 2013 7:10:59 AM UTC-7, Sanjay Parekh wrote: > On Wednesday, June 19, 2013 11:13:52 AM UTC-7, Sanjay Parekh wrote: >=20 > > On Tuesday, June 18, 2013 10:06:32 AM UTC-7, Kevin Neilson wrote: >=20 > >=20 >=20 > > > I discovered one cause (but not all) of the coredumps I experience. = If I had mismatched port widths in a VHDL instantiation, I'll often have co= redumps. There is no indication of what is wrong, but now I know what to l= ook for in some cases. I also suffer all kinds of problems when I try to u= se unconstrained outputs based on unconstrained inputs, to the point where = I just have to avoid that feature of VHDL. >=20 > >=20 >=20 > > >=20 >=20 > >=20 >=20 > > >=20 >=20 > >=20 >=20 > > >=20 >=20 > >=20 >=20 > > > I think it'd be great to have a cloud service you could use if you di= dn't need to use it that often, but I don't know if that would be profitabl= e for Mentor. >=20 > >=20 >=20 > >=20 >=20 > >=20 >=20 > > In my case, the tool choked miserably whenever I misinterpreted the sys= temverilog spec and hooked up interfaces incorrectly. =20 >=20 > >=20 >=20 > >=20 >=20 > >=20 >=20 > > In my opinion Mentor can use the cloud platform quite creatively and ma= ke a business out of the unmet need which is allowing engineers to build my= riad pieces of ip that serve niche areas without going through a vetting pr= ocess to justify a big budget and therefore a big market. >=20 > >=20 >=20 > >=20 >=20 > >=20 >=20 > > And think of the community schools that generally offer programs in c p= rogramming, etc. Why not programs in verification, linting, scripting, sim= ple designs, etc.? More side opportunities for consultants/senior engineers= as trainers, more opportunities for the students to learn online. E.g. If= coursera/udemy can offer software courses, why not hardware courses as wel= l? And think of kickstarter/indiegogo which can fund those hardware projec= ts. >=20 > >=20 >=20 > >=20 >=20 > >=20 >=20 > > Enough said. I don't mean to say that cost of the tools is the only th= ing that is preventing massive innovation in the hardware development. But= I feel it is an important part as it limits the creative ability of the pe= ople who can make a difference. >=20 >=20 >=20 > Interesting read today if you can see as I do the opportunities for cloud= based tools.. http://gigaom.com/2013/06/19/open-compute-is-bringing-the-ma= ker-movement-to-the-enterprise/?utm_source=3DGeneral+Users&utm_campaign=3D3= 472bd888e-c%3Atec%2Capl+d%3A06-20&utm_medium=3Demail&utm_term=3D0_1dd83065c= 6-3472bd888e-98983131 Aldec seems to get it. So does Altera. Read an interesting article today.= Looks cloud based tools are coming. http://eecatalog.com/fpga/2013/02/06= /practical-applications-of-cloud-computing-in-semiconductor-chip-design/Article: 155368
Verilog code for my Hive processor is now up: http://opencores.org/project,hive (Took me most of the freaking day to figure out SVN.)Article: 155369
rickman wrote: > I didn't think it was in the VHDL because it had been simulated well and > the nature of the bug is an occasional dropped character on the receive > side. Who can't design a UART? Well, it could be in the handshake with > the state machine, but still... > Any time you recompile an FPGA and the problem disappears or changes, it is a STRONG indication it is a timing problem. Regenerating the place & route changes timings subtly between sections, and may eliminate a marginal setup or hold time problem. You should make sure all signals that cross clock boundaries are properly synchronized, and that you are giving the right clock specification to your clocks in the ucf file. If there are tricky timings on parts connected to the FPGA, then you need to define the timings in the ucf file. JonArticle: 155370
On 6/24/13 5:03 AM, Eric Wallin wrote: > On Monday, June 24, 2013 3:24:44 AM UTC-4, Tom Gardner wrote: > >> Consider trying to pass a message consisting of one >> integer from one thread to another such that the >> receiving thread is guaranteed to be able to picks >> it up exactly once. > > Thread A works on the integer value and when it is done it writes it to location Z. It then reads a value at location X, increments it, and writes it back to location X. > > Thread B has been repeatedly reading location X and notices it has been incremented. It reads the integer value at Z, performs some function on it, and writes it back to location Z. It then reads a value at Y, increments it, and writes it back to location Y to let thread A know it took, worked on, and replaced the integer at Z. > > The above seems airtight to me if reads and writes to memory are not cached or otherwise delayed, and I don't see how interrupts are germane, but perhaps I haven't taken everything into account. > Consider a case where *both* thread A and B want to increment a counter at location X? A reads X and finds it contains 10. But before it can write back 11, B reads X and finds 10 and it too writes back 11. Now you've lost a count. Can this happen in your design? If so you need some sort of atomic update instruction.Article: 155371
On Monday, June 24, 2013 6:03:38 PM UTC-4, Bakul Shah wrote: > Consider a case where *both* thread A and B want to increment > a counter at location X? A reads X and finds it contains 10. But > before it can write back 11, B reads X and finds 10 and it too > writes back 11. Now you've lost a count. Can this happen in your > design? If so you need some sort of atomic update instruction. It can happen if the programmer is crazy enough to do it, otherwise not. Anyone have comments on my paper or the verilog?Article: 155372
From a SW point of view, avoiding extra comparisons when not needed is valu= able. From a HW point of view, that is not necessarily so. Unless the compa= risons are (or can be) at different times and reuse the same comparison log= ic, there is no benefit to avoiding a comparison if it might have to be don= e. The logic to decide whether a comparison needs to be done needlessly add= s to the complexity of the circuit.=20 AndyArticle: 155373
Bakul Shah <usenet@bitblocks.com> wrote: (snip) > Consider a case where *both* thread A and B want to increment > a counter at location X? A reads X and finds it contains 10. But > before it can write back 11, B reads X and finds 10 and it too > writes back 11. Now you've lost a count. Can this happen in your > design? If so you need some sort of atomic update instruction. In the core memory days, there was a special solution. Core read is destructive, so after reading the value out it has to be restored. For read-modify-write instructions, one can avoid the restore, and instead rewrite the new value. That assumes that the instruction set has a read-modify-write instruction, a favorite for DEC machines being increment and decrement. DRAM also has descructive read, but except for the very early days, I don't believe it has been used in that way. If the architecture does have a read-modify-write instruction, such as increment, it can be designed such that no other thread or I/O can come in between. -- glenArticle: 155374
I did not mean to imply that the implementation needed to use stacks, but t= he card game usually would. In HW, only a single value ever need be retriev= ed from a stack, so each stack is only one deep (a single register). You may be right about the same or higher. The results are the same, but th= is really depends on what one means by "2nd highest value": is it the secon= d of the two highest values seen, or is it the second highest unique value?= If I draw two kings and a deuce, is the "second highest card" a king or a = deuce? Either comparison gives the same result, since if the 2nd king failed a hig= her (only) comparison with 1st highest result, it would still pass the high= er comparison with the 2nd. If you wanted to find the two highest unique va= lues, more work would be required. Andy
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