I Have Done IT! (Increased the speed of a serial task) - Page 1
Forum section: electronics / projects

author: adept
author_rank: Regular Contributor
timestamp: January 27, 2013, 03:29:22 am
content: After a lifetime (or about 4 years for me... I'm only 17 after all!) of hard work and effort, I'm prepared to announce to everyone an amazing discovery that will revolutionize massively parallel computing forever! So let me tell you about the details of it...First, download the attachment in this post. Change the extension to .zip and extract the files contained within... (Dave, don't kill me for that, it's for a good cause!)This computer is a hypothetical, yet entirely achievable computer. It is based on an OISC core that relies on "add and jump if greater than overflow." This kind of computer is, remarkably, Turing complete. I have a simple simulation set up so anyone of you guys can behold it's splendor. First you will have to download Logisim (http://sourceforge.net/projects/circuit/). That will allow you to open the file in the zip attached labeled "OISC Rev 4.circ". That file is an OISC computer. Some example programs are included. Right click on the two rectangles labeled "ROMs" and load the ROM that corresponds to it. (Top ROM programs go into the Top ROM...) The HelloWorld program kinda sucks.... I just told the program to spit out garbage because I hadn't figured out how to get meaningful text yet. And the Math Program has a bug in taking input where you have to press the key twice and it also gives weird answers. I never claimed to be good at programming in binary!lolSo that was many ages ago that I created that OISC computer. You'd be surprised from looking at how terrible that design was how terrible the other 3 revisions were!But I persevered through the years and eventually built up this little circuit. The file in the folder labeled "OISC Computer Design" contains my KiCad project. (http://www.kicad-pcb.org/display/KICAD/Download+Kicad) Yeah, more software to install, ik ik. But bear with me. At this point, I was able to connect the OISC computers in parallel to do cool things like Median Filters. But I learned quickly that no matter how many of these you put in parallel, the memory in the computer will bottleneck anything you do. So I set out to make a new kind of memory that suited my needs.Anyway, that was an entire other side path. Many many designs later, and I just got something that you guys will probably recognize as shared cache. My own design has the same functionality, but a unique and insane design of my own. But I'll include my design, just for record keeping purposes!(It's labeled "Sharable RAM.circ")So, combining all of these together, I give you my scalable serial speed simulator. The file called "a.out" was compiled by GCC. I don't wanna give source out quite, as this hasn't been publicized like those other two projects have. 1 stage doesn't make sense to the simulator. That would be simulating just one core, which it hasn't been designed for. And anything over 3 cores overflows my computer, so I added a line in the code that prevents you from falling victim to the same!The program that it is set on executing is just:"int main(void){//these can be whatever, but 1s were picked for convenience in the example.int a = 1;int b = 1;while(a<overflow) a+=b;}"This task is serial. The next result depends on the previous. Yes, I know this can be parallelized by the associative property of addition. Iassureyou that that is not the case here. (otherwise I wouldn't be so excited!) What is happening instead is that it is parallelizing all the possibilities that could happen in the first step and then assembles the right answer. My dad compared it to the old joke that if a million monkies sat at a typewriter and typed that eventually one of them would type the entire works of Shakespeare. The only difference is that, in this case, the program can control the output. It's like a giant lookup table of numbers that is generated each time the program is run, allowing it to change. The only downside of this is that it takes 16.7 million cores to double the speed of a simple 8 bit computer, but the bright side is that it only took half the time!So I have some equations to describe the return you will get from adding more cores...curse me, imageshack won't let me upload right now. It's just the summation of 2^wordsize*stage_num+1and then the return is:stage_number/2.At the second stage, you barely meet back up with 1 clock cycle per clock cycle. It takes an INSANE amount of cores to double the speed of just an 8 bit computer, but the cool thing is that the possibilty is there. It totally proves Amdahl's Law wrong! It just makes me happy to think about it....What do you guys think of it? I don't want to give away too much about it. But if you guys wanna ask some questions, go ahead. It will help me do better at the science fair this year that I'm entering this into!

author: GeoffS
author_rank: Unknown
timestamp: January 27, 2013, 05:22:49 am
content: The chances of anyone running an unknown executable are slight, or at least I hope people know better.

author: adept
author_rank: Regular Contributor
timestamp: January 27, 2013, 06:14:04 am
content: Haha, I know what you mean! Hm.... I don't know how to do it any other way. You could scan it for viruses.... But the odds of my little a.out being in the repository would have been slim. I dunno how to say it except to say that you can look at the things I've done for the forum and cross your fingers that I'm not an insane psychopath that wants to harm your computer. Or I could give you guys the source, but then any hopes I have of keeping the intricacies of my program out of reach are out of the question. Of course any patent stealing rubbish bag could have already decompiled my a.out and gotten the information out. Besides, then what am I doing on an open source kind of website? I guess I can post up the source and you guys can compile it yourselves.... Just know I'm a little conflicted!(Also, excuse the spaghetti. C isn't my first language to say the least! lol) Also, since it's up, I might as well spend a few hours when it's not midnight and comment it a little so you guys can see what's happening. If you look at the PDF attached, you can see a basic block diagram. It should help clear some stuff up too!

author: adam1213
author_rank: Regular Contributor
timestamp: January 27, 2013, 12:50:54 pm
content: You really should work on formatting your code and using better variable names. Doing so would make it easier to see what the code is doing.Are you sure the result you are getting is correct? I see accesses to memory that has not been allocated which means the behaviour of your program is undefined.An example of accessing memory that has not been allocated correctly from the code posted:Code:int answer;....for(counter_2=0; counter_2<65536; counter_2++){if((answer[2*counter+2])==(answer[counter_2+514])-b){ // The array is of size 65536, arraySize*2+2 is clearly outside the array.Reasoning about computer architecture at the age of 17 is impressive.

author: Mechatrommer
author_rank: Super Contributor
timestamp: January 27, 2013, 03:59:21 pm
content: Quote from: adam1213 on January 27, 2013, 12:50:54 pmindeed. even more to parallelism. can i get references for the basis of the OP's machine?

author: grumpydoc
author_rank: Super Contributor
timestamp: January 27, 2013, 04:14:01 pm
content: Quotehttp://en.wikipedia.org/wiki/One_instruction_set_computer

author: Mechatrommer
author_rank: Super Contributor
timestamp: January 27, 2013, 05:44:06 pm
content: thanks. which lead me to this quote from OP...Quote from: adept on January 27, 2013, 03:29:22 amnow thats a "claim"! you should join "the conference", your name could be carved in the wiki for a very very long time. eevbloggers have no credible capability of such magnitude, AFAICS at least.this reminds me of my young age 18, where i proved "the area of a circle" is not pi.R.squared using "the first principle" integration. but i have no mentor to analyze my method and no internet to post back then, so the idea just dissapeared and never materialized. i've forgotten how i derived the formula and the formula itself.

author: marshallh
author_rank: Unknown
timestamp: January 27, 2013, 07:56:58 pm
content: Where's your decoupling caps on the pcb... no wonder you are getting weird resultsI think you should look into FPGAs, massively parallel algorithms can be quite powerful, but also inflexible.

author: adept
author_rank: Regular Contributor
timestamp: January 28, 2013, 02:28:01 am
content: Alright. This is going to be a little session I guess...Quote from: marshallh on January 27, 2013, 07:56:58 pmThe decoupling caps aren't necessary because the clock rate is so low. And that would cause glitches instead of me being able to get a consistent and predictable answer...I have looked into FPGA's. But, I haven't any education in Verilog in the slightest. I have taken C classes... So I modeled it in C. I haven't been able to self teach myself Verilog.... All the tutorials online kinda suck for newbies like me. They all rely on you taking a class at uni and they go alongside with that. And also consider that here in NM, there isn't any kind of a VLSI school. The uni I live by is NMSU, which specializes in Mechanical Engineering. I don't even know where I learned everything I have... Probably from being wrong so many times!Quote from: Mechatrommer on January 27, 2013, 05:44:06 pmNo reason to quote the first part... But yeah, no need to be so sarcastic!It's cool, I get that my claim is pretty bold. But take a look at Gustafson... He proved Amdahl wrong already. Nobody quotes him, do they? What I mean to say is that Amdahl's law only applies to the system he was talking about. In that system, it is perfectly correct. Indeed, when I parallelized my OISC computers last year, I found him to be almost spot on. I got about 97% of the return that his equation had predicted for me and I had concluded that he was entirely right. But this time is different. What I should have said is that his law doesn't apply to my system, only the one he was talking about. My system isn't the system that he has. Mine is a crazy tree network that preprocesses things before they happen. Think of it like a carry lookahead adder. It calculates the probable carry bit based on what makes sense for it, before it happens. Call me crazy all you like, but I'm not stupid... I'm not hyping something to hype it. I'm hyping it because I feel it is worthy of the hype. Now, off my soap box!Haha, I know exactly the proof you are talking about. You start with a unit square and start making a plus with sides 4 and then do the same process until you prove that pi = 4... lol, I'm EXACTLY that kind of person!But this isn't one of those times, I really think I've found something interesting here.Quote from: grumpydoc on January 27, 2013, 04:14:01 pmlol, couldn't have explained it better myself! There is an "A" operand, a "B" operand. They are added together. If A+B > overflow, it branches to address "C". It's really that simple guys! It's kind of obscure because it is very slow. It takes like 20 serial tasks to execute a simple inversion command! (I don't remember the exact number... I think it's actually closer to 10... 12 maybe?)Quote from: adam1213 on January 27, 2013, 12:50:54 pmThat's weird.... I should have caught such a blatant error. Stupid GCC didn't even give me a seg fault... That's really embarrassing. And it didn't give a weird answer to boot. It gave me EXACTLY what my math had predicted. I would just change that number to 131586 (2*(65536+256+1)), which is the maximum that would be accessed!The code was pretty rushed. I usually comment the crap out of code... I'll do that later though, after I figure out how to get the recursion algorithm for the stages working.... It's really gross in the form it is in! (I just thought of this!it's another reason I didn't release the source! lolYou know, because it's so terribly written!)And thanks! That's the usual response though. Despite the mistakes I make, I do actually know more than what comes out sometimes!Whew! Thanks for responding guys. I was up till like 1 am last night and only one guy had responded! He told me to put up my source, and what do you know? Everyone starts posting things!Thanks Geoff! It was a pretty good idea if I say so myself. Also, has anyone looked at the pdf I had attached? It has a pretty nice diagram of my thinking. And for grins, you guys should mess with the value of "b" in the simulation function. (Hindsight says I should have split up my files like I usually would have...)

author: onlooker
author_rank: Frequent Contributor
timestamp: January 28, 2013, 03:15:12 am
content: QuoteI at least would doubt the judgment of announcing a great "Discovery" in such a style (It sounds like the perpetual machine style). How many other places have you done such announcement?I hope you have already written a scientific paper about this "Discovery" of yours and sent it to one of the IEEE journals (or the equal). If you have done that, please please do let us know the results, be it good or bad. If you have not done so, would you care to predict the chance it would be accepted?

author: GeoffS
author_rank: Unknown
timestamp: January 28, 2013, 03:23:37 am
content: Post your discovery on a computing science or programming forum and get some peer review.

author: Mechatrommer
author_rank: Super Contributor
timestamp: January 28, 2013, 03:51:16 am
content: Quotefrom what i understand reading the wiki, his law is pretty generic, ie the fastest execution time of paralleled algorithm will be bottlenecked by "unparalled portion" of the algorithm. so maybe in your case, there is no "unparalleled portion" hence you can execute it in "true paralleled" time , ie "serial execution time" / "number of cores". maybe you should test your machine for the case of an algorithm that contains "unparalleled algorithm" (codes or semantics that cannot be paralleled).i have no time to carefully study what those people means in their law, but since law can be broken, so does Gustafson's i guess... let me do a "quick quoting" some of the limitation of his law from the wiki...Quote

author: DavidDLC
author_rank: Frequent Contributor
timestamp: January 28, 2013, 05:47:58 am
content: Quote from: Mechatrommer on January 27, 2013, 05:44:06 pm

author: adept
author_rank: Regular Contributor
timestamp: January 28, 2013, 07:18:51 am
content: Quote from: onlooker on January 28, 2013, 03:15:12 amQuote from: GeoffS on January 28, 2013, 03:23:37 amI wouldn't know how to do that. I have never really published anything before. I'm not even a member of the IEEE. I sort of have an account with them. I don't even remember why I did it, yet alone what my password was. All I remember is that I couldn't do anything because I wasn't a member of theirs and I didn't subscribe to their catalog. So, both of you guys have a great idea, but I don't know how to publish it. Curse me living in a tiny town.... The best I could do is post it up on something like StackOverflow. But they aren't as friendly as you guys... I might post it up for grins! lolQuote from: Mechatrommer on January 27, 2013, 05:44:06 pmI'm not sure if you are quoting somebody or not.... Mechatrommer never said "If you discovered something very important, how can you lost, forget, don't remember how you did it?..." And I had already explained exactly what he meant. In fact, ViHart on YouTube has even done a whole video on that proof.... Just look up "proof that pi = 4" on YouTube... Anyway, if you really wanna have a math war, you can start your own thread. This is about my computer! lolQuote from: Mechatrommer on January 28, 2013, 03:51:16 amYour comment is indeed the most difficult for me to address... It required me to go back and check up on Gustafson's short little 2 page paper entitled "Reevaluating Amdahl's Law". Don't wikipedia the law, the article kind of stinks. If I had a little more time, I might propose some changes to make the effects more clear... But basically, Gustafson is saying that the actual increase in speed doesn't follow quite as sharp a downward curve as Amdahl had suggested. He just changes the Amdahl equation around a bit to accommodate for the fact the programmers can utilize the cores better than the strict Amdahl law had assumed. Amdahl had merely assumed that the programmer would keep the program the same as more cores were added. But yeah, Gustafson's law doesn't apply to mine. He didn't increase the serial speed, he just added in that programmers are smarter than Amdahl thought! lolEdit:: I see what happened.... I don't see why the quote thing is working so funny... That's not good!

author: AndyC_772
author_rank: Super Contributor
timestamp: January 28, 2013, 07:58:31 am
content: Quote from: adept on January 28, 2013, 02:28:01 amThe need for decoupling depends on the switching speed of the device and the amount of current which the device draws each time it switches, and not on the clock rate. When a CMOS device switches state, it draws a brief pulse of current from the supply, and the decoupling caps are required in order to ensure that the power supply doesn't momentarily drop out of spec due to excess impedance. If it does, the logic state of the device can be corrupted.It doesn't make much, if any, difference how many times/sec this occurs. If you're clocking your logic at, say, 1 MHz, the switching events still have the same duration (probably <1ns) as they would if you clocked your logic at 100 MHz. The only "benefit" of a low clock rate in this regard is a statistical one; if a given switching event has a one-in-a-million chance of a logic error due to poor supply decoupling, your circuit will run error free for longer (on average) before erroring than if your clock rate were higher.Properly decoupling the supply to a logic circuit really has no downside, other than the cost of a few caps and the effort required to add them correctly. It certainly won't "cause glitches" to include them - quite the opposite.

author: jnd
author_rank: Regular Contributor
timestamp: January 28, 2013, 08:17:51 am
content: Quote from: AndyC_772 on January 28, 2013, 07:58:31 amYeah, for a long time I thought the same when I started playing with AVRs, it worked fine without caps when blinking LEDs or other simple tasks. The whole size of the current loop from cap to the IC actually matters as I learned on the breadboard. I was generating just 750 kHz dual phase clock for Intel 4004 system that was on the same board, no external crystal and there were already problems with ICs switching at sub MHz speeds, it kept randomly restarting. Other case was running just one old MCU with external memory on top at whopping 2 MHz. Problem was most likely bad connection by oxidized wires to power supply and decoupling caps. I had to check with logic analyzer because the processor was running all over the memory places, accessing addresses that was never supposed to. This can happen very easily and it's a real problem.

author: Mechatrommer
author_rank: Super Contributor
timestamp: January 28, 2013, 11:09:37 am
content: Quotei dont blame you for being "scientific" mindyou cant believe what you cant see or sense. i tried to remember it but it involved (associative?) calculus method that i've forgotten, i cant find the book anymore that presents the proper steps on how did i manage to get there. that was my first year when we leart all the nonsense calculus mostly not used in engineering subjects.why i've forgotten it? i was not that too optimistic (and still is), i mean who am i to change the world and proved archimedes is wrong? i might slip some errors in there who knows? so i didnt bother too much, i just follow the trend. i am an engineer (wannabe) and always is, not a scientist or mathematician. did you remember the engineer vs scientist joke? engineer will say "that is good enough" scientist say "that is infinitecimal", i love the "good enough" part"good enough" is good enough for me. pi.R.squared is "good enough" ya know what i'm sayin'?edit: i only remember this step, i hope someone with brilliant mind can help me to continue. for a circle, its x^2+y^2 = r^2, we only take 1st quadrant for simplicity, the end result will be multiplied by 4. then we got y = sqrt(r^2-x^2), there's the problem of integrating square root, anyone?. to get area of circle we integrate each small rectangular shapes dA = y.dx, thats where i tweaked it, instead of taking rectangle area, i took trapezoidal area so the integration will be like... dA = ((y + (y-dy)) / 2).dx, from there on i've forgotten how did i continue, we'll need all the fanciness of associative calculus after that.anyway, i'm going to figure out how to build a ±240V 100MHz FG, i have no time for this mathematical bullsheet. cheers

author: HackedFridgeMagnet
author_rank: Super Contributor
timestamp: January 28, 2013, 11:50:18 am
content: Hi Adept, have you readhttp://spartan.cis.temple.edu/shi/public_html/docs/amdahl/amdahl.htmlThis guy had some thoughts about Amdahl and his law.SpecificallyQuoteAnyway ignore naysayers such as me (in this instance), the best discoveries are made that way.Happy processing.

author: Mechatrommer
author_rank: Super Contributor
timestamp: January 28, 2013, 12:08:20 pm
content: back to topic... the OP complained about his limited resources. my suggestion is, maybe you can make a letter to NASA to ask them to run your model in their super computer, so you can sim how well a sort algorithm performs on your machine, how many clock cycles it can be completed. try Gonnet-Baeza method to sort 100 items for a start first, my 2cnts

author: penfold
author_rank: Frequent Contributor
timestamp: January 28, 2013, 02:18:55 pm
content: adept, if you do prepare a paper for an engineering journal, PM me for my details I would be happy to be suggested as a reviewer - I've been reviewer for similar papers in the past.

author: adept
author_rank: Regular Contributor
timestamp: January 29, 2013, 12:22:01 am
content: Quote from: penfold on January 28, 2013, 02:18:55 pmI have a paper I wrote for the STS scholarship. But it was from before I did all this.... I'm pretty familiar with writing them, it's just that I don't have any way of publishing them.... Lemme attach the paper for you.... You can just take a gander at my immature writing style for a while!lol (I didn't get the scholarship btw. In fact, I'm not really sure who did. You can just count on it being "blah blah Cancer blah World Peace" or some variation of that! lolQuote from: AndyC_772 on January 28, 2013, 07:58:31 amThat is very cool information to know. I have never had any problems with it before though. Keep in mind that 30 TTL chips hardly constitutes any huge spike in current.... But if they are there to prevent spikes in current, why in the world would you need a zillion of them right up against the chip? It doesn't make sense to me quite yet. I would have thought that they were across the power supply to allow any AC that was coupled to the 5V rail by the thousands of signals going every which way to ground, but not allow the DC to go through. I would think that a power supply filter cap (which I have...) would be enough to deal with 30 mA spikes in current.... lol Maybe you could give me a lecture on it sometime. I love to learn things about electronics!Unfortunately, I have only learned from reading books like "The Art of Electronics" and from experience, not from school... Is that a common misconception you've seen in people? (Or am I just crazy?)Quote from: jnd on January 28, 2013, 08:17:51 amYeah, you definitely confirmed what Andy had said. I just have never learned that and had assumed something that was incorrect. I'll add that in future revisions. (If I ever get that far!) Keep in mind that I have never had trouble with it before. I build my own power supplies and I don't use breadboards very often. I typically will design a schematic, simulate it, put it on a PCB, build it up and troubleshoot for a while...It's probably not the best process, as I don't really have a real world simulation going until I've made the PCB, but yeah, I also make my own PCBs by hand. I'm pretty good at it too. Took lots of practice. Glad to hear that your AVR problem got solved though!Quote from: Mechatrommer on January 28, 2013, 11:09:37 amlol, I'm not following what you are saying this time buddy!Glad to see you brought us back on topic though... Thanks for that! And yes, electronics is funner than math. lolQuote from: Mechatrommer on January 28, 2013, 12:08:20 pmHaha, I've quoted the entire topic again!I'm not sure in forum etiquette if that's okay? Maybe a moderator can tell me.... Anyway, until I get the recursion working on my algorithm, I won't be sending anything to NASA. And wouldn't you know, I live only about 5 minutes away from NASA... I could probably send it in with my friends dad there who works on making maps of the planet... He uses super computers for that! But first, maybe you or someone else could try helping me set up the recursion in my simulation or take a closer look with the edits We've decided on in this forum (To increase the size of the array basically) and see if it really makes sense or not. No need to try to simulate something that doesn't have any real world connections...Anyway, I'm going to tab over to gEdit now and work some more on getting the function to work correctly....

author: AndyC_772
author_rank: Super Contributor
timestamp: January 29, 2013, 07:55:01 am
content: Quote from: adept on January 29, 2013, 12:22:01 amThey don't prevent spikes in current when the device switches, they supply them.The key point to be aware of here is that every wire and PCB trace has inductance, and that the current through an inductor cannot change rapidly without there being a voltage across it according to V=L(dI/dt). The inductance of a trace is of the order of 1nH per mm.When a CMOS device switches state, the resistance between its power and ground pins momentarily decreases, so it draws a pulse of current. The rate of change of current dI/dt is very large, and so the voltage developed across the trace linking the device to its power supply can be very significant unless measures are taken to minimise L. The way that's done is to use power and ground planes instead of traces, which has a direct effect on L, and to place a good quality capacitor physically very close to the chip. The capacitor effectively assumes the role of the power supply at high frequencies, keeping the distance (and therefore the inductance) to a minimum.You don't need that many; one per power pin is the normal rule of thumb, though there are cases when more or fewer caps are appropriate. Placement and quality of PCB layout are key.QuoteBear in mind we're talking about very brief current spikes, which can be much more than 30mA. If 30mA is the average power consumption of your circuit, it could be that it's actually drawing 3A with a 1% duty cycle.I know we're taught in school that capacitors block dc but allow ac to pass, and whilst that's certainly true, that description tends to imply that the cap is being used in series with some other device. I don't personally find it a particularly helpful way to think about them. Think instead of a slightly more general description: a capacitor has very high impedance at dc, but low impedance at ac.At the sort of frequencies you'll find during a CMOS switching event, the impedance of a ceramic capacitor would be essentially zero if it weren't for the inevitable inductance that gets added in series as soon as you connect anything to it. It has a little series inductance of its own too, though this is usually small compared to the PCB trace inductance on most layouts - but I digress.The point is that, at ac, the capacitor is a very low impedance device, so it maintains a fixed voltage even if a large (but brief) current spike is drawn by the load. The power supply - big, heavy and miles away - only has to provide the dc current drawn by the product as a whole, and the decoupling caps supply the very high frequency currents the individual chips require when they switch.(At the very highest frequencies, say 500 MHz+, the parasitic inductance in series with the caps becomes dominant and they so they stop working effectively. Above this frequency it's actually the capacitance that exists between the power and ground planes of the PCB that provides the decoupling - which is another reason to use multilayer PCBs).QuoteThere are certain important aspects of electronics which can't easily be learned correctly just through practical experience, and high speed design is one of them. You won't learn this stuff at school either, it's degree material - but it's not actually that difficult. Next time you get the chance to pick the brains of a degree qualified design engineer, do so. There are training courses run by industry too; if you ever get the chance to attend a course run bythese guys, do so.

author: adept
author_rank: Regular Contributor
timestamp: January 29, 2013, 11:22:48 pm
content: Thanks Andy. I'm not using CMOS though... I'm going to assume that the same thought process would apply for TTL though as well? lol Not to be a troll or anything!I might spend a few minutes today messing around with some caps on the board I've built up... Have to bodge them in I guess... haha Seems I only have ceramics in the pF range though. It's the radioshack bag! It's pretty terrible. All my nF caps have gone to crystal clocks....If you have looked closely at my PCB, you will notice how long my power tracks are.... Maybe I should have gone 4 layer and put in some ground planes. If the cause of the problem is inductance, then having power planes would relieve that problem as well as add in some nice capacitance just in the PCB. It would help keep my design more dense that way also. Anyway, I guess I'm just saying that if the layout is key, I sure didn't put much thought into it. I just placed things close that were close in schematic and then let KiCAD do the rest! And that's never failed me before.And thank you very much for the rest. It now makes sense why I don't see decoupling caps on super high frequency stuff. In fact, now that I think about it, I don't see why I ever thought that decoupling caps were for high frequencies. I have only seen them on really old electronics.... at super LOW frequencies. New electronics don't have anything like it. Funny how it is after you learn something. Makes you look back and see how wrong you were in the past!

author: AndyC_772
author_rank: Super Contributor
timestamp: January 30, 2013, 08:12:45 am
content: I've not seen your PCB (can you post PDFs or Gerbers?), but from what you say it sounds like it's a 2 layer board with routed power and no decoupling - right?Sometimes you'll get away with it, but it's a problem waiting to give you all sorts of grief. Data errors due to high speed switching problems are very hard to track down, and if you get them, the only reliable fix is to lay the board out properly. There's no short cut or retro-fit "fix". TTL behaves a bit differently to CMOS, but the best practice layout is still the same.I'm not sure what designs you've seen that look as though they don't have any decoupling caps, because any modern high frequency design will require them. Even if they're not needed for functional reasons, a board that's not properly decoupled is very likely to fail mandatory EMC testing.Let me conclude with a little story...My electronics A-level project was a microprocessor system with a CPU, RAM, ROM, a simple display and keypad, and some analogue I/O. It was built using a set of solderless breadboards clipped together, and with hindsight it was stupidly over-ambitious, but back then I was keen!At one point in the project's development, it would boot up OK and show the proper information on the display, but as soon as my hand approached the keypad, the display would fade out. I didn't have to actually touch it, just being within a couple of inches was enough.The fix turned out to be to add a whole bunch of additional power leads, to make a much better job of interconnecting the different breadboards, and to decouple each logic IC with a ceramic capacitor placed right over the top of the device and connected directly to its power pins.A single wire linking the supply rails between the individual breadboards had too much resistance and inductance, and allowed a voltage to be developed between GND at the keypad/display board and GND at the CPU. As seen by the display driver, this voltage appeared superimposed on the logic signals from the CPU, and made it misbehave.Ever since then, I always look long and hard at any board which includes routed power instead of a plane, and I'm very fussy about decoupling cap placement and routing - and I've rarely if ever had a problem in this area since.

author: Mechatrommer
author_rank: Super Contributor
timestamp: January 30, 2013, 10:43:22 am
content: the zip file contains everything including the pcb gerber and drill files, thats the positive side. the negative is.. whats lacking is properly arranged or spaced schematics for easy to read and documentation explaining the idea, concept (abstract) and implementation flow (methodology), which i believe necessary for "council" approval. the reviewer is assumed to be already an expert in this area. my 2cnts.

author: mrflibble
author_rank: Super Contributor
timestamp: January 30, 2013, 11:05:45 am
content: Quote from: adept on January 28, 2013, 02:28:01 amFPGA recommendation seconded. They are a very good fit for this sort of problem. As for learning verilog ... just a book or two + online tutorials + lots of try and fail and try again can do the trick as well. No need for a formal HDL program at uni. I used "A verilog HDL primer" from Bhasker to learn the basics.Not that I am now the world's greatest HDL coder, but at least it's better quality than opensores.org I know, I know, setting the bar low.*grin* Just checked, and opensores.org actually exists. XDAs for the matter of getting a review, peer flavored or otherwise ... working on readability of code + having a good design document really helps there.And yes, please use caps even if yourswitching rateis low. Fast logic will still cause transients that can cause all sorts of funky stuff where you least expect it. And generally speaking ... TTL probably even more so than CMOS, due to more charge being pumped around.

author: adam1213
author_rank: Regular Contributor
timestamp: January 30, 2013, 11:26:45 am
content: Quote from: adept on January 28, 2013, 02:28:01 amI wish all invalid memory accesses would be easy to detect rather than occurring silently.Segmentation faults occur when a program attempts to access a region of memory in its world (address space) that it's permissions don't allow. Accessing memory outside a given array won't always cause a seg fault as the region may be permitted.If you want gcc to be clever and warn you about most memory accesses issues you can use mudflap. To use it compile using "gcc ....normal flags... -fmudflap -lmudflap"* getting mudflap to work may require installing packages (e.g. libmudflap0)* mudflap will slow the execution of a program down as it performs run time checks

author: mrflibble
author_rank: Super Contributor
timestamp: January 30, 2013, 12:10:48 pm
content: I vaguely recall there being some issues with libmudflap and multi-threading. Other than that, using something like mudflap is a good idea if your code is a bit creative in the memory management department...Oh and pedantic point .... gcc won't segfault due to your code content. It's your runtime binary that does the segfaulting. If your gcc segfaults you have bigger issues. ;-)

author: Mechatrommer
author_rank: Super Contributor
timestamp: January 30, 2013, 12:30:37 pm
content: the worst? bugs turn into features!

author: mrflibble
author_rank: Super Contributor
timestamp: January 30, 2013, 12:37:02 pm
content: You mean like termites and "topological features" in wood?

author: adept
author_rank: Regular Contributor
timestamp: January 31, 2013, 12:04:19 am
content: Mechatrommer, I have a block diagram attached to one of my later replies. It shows visually the information that I used in my head to come up with the design.Code commenting is under way. I started the program over again and am having problems with getting the recursion to work. The new program isn't working as I want it to yet. I'll post it when I get that to work correctly. My brother should be able to help... he is a CS major after all!I gotta say that mudflap is a pretty funny way of thinking about what is happening here!It is catching all the "mud" that is your code from getting all over everything! Anyway, I tried it and it indeed returned an error with my code. Go figure. That is definitely something I'll be sure to check before I post any more source with the working recursion algorithm.Anyway, not much time to work on anything important tonight. It's the middle of the high school work week and I have other things to worry about before Saturday!(AP US History... curse the irrelevancy of high school courses to real life!)

author: adept
author_rank: Regular Contributor
timestamp: February 03, 2013, 04:26:11 am
content: I've slopped together a very rough rough draft of the paper I need to submit by Friday. It took me all day, but it's there. There are some semi-major flaws in it that I found already but don't feel like fixing tonight. The equation on the last page that gives the number of cores is missing a summation 1 to k on it and the abstract has a header and it shouldn't.... It's definitely got some work to do. But it is the first copy I have that is under the word limit and contains all the required information. Hope you guys tear it to pieces!Cheers

author: mrflibble
author_rank: Super Contributor
timestamp: February 13, 2013, 05:22:10 pm
content: Seeing how it is past the previously mentioned Friday ... how did that go?During a quick read I noticed a few things, but chances are you already have a better version. Anyways, you may want to read up on speculative execution and speculative branching, since some of the claims of "X has never been done before" I found to be a bit ... inaccurate.Oh yeah, as for simulation. You may want to look into an evalutation version of modelsim. Or maybe ISE or Quartus from Ye Olde FPGA Vendor. You can still do schematic capture there if you want to, and for bonus points you can start dabling a bit in verilog or vhdl.

author: adept
author_rank: Regular Contributor
timestamp: February 13, 2013, 11:27:34 pm
content: The recursion algorithm didn't ever get working. So I continued with all the other simulations I had and finished off the paper whose deadline was looming. I am literally being swarmed with different busy things to do.The speculative branching is not exactly like this at all... It does indeed use the same concept as speculative processing, but it does all of this at the hardware level. This is something a step above and beyond what old methods have used. So the answer is yes, some aspects are unoriginal, but there is at least something about it that hasn't been done in the past.Modelsim is new to me. I am a student, so I think I can get a copy for freebies. But today is a busy day. Tomorrow will yield more time to look into that further. Gotta go to mass in a bit....TTYLedit:This is a graph that shows the return of adding more stages. It all experiences a severe diminishing return. The amount of power for a very tiny increase in speed is enormous. Just thought that you guys might be interested in seeing a diagram showing some of the results I have. Notice that it is not even linear on this logarithmic scale. It has a curve to it because it is a limit of a summation. An integral if you will. The stages are cumulative....Hope you guys like it!

author: AndyC_772
author_rank: Super Contributor
timestamp: February 14, 2013, 09:28:03 am
content: You can get ModelSim for free by downloading the Web edition of Altera's Quartus II development software. It has some limitations on code size and simulation speed, but it's still a very useful and capable tool.