|
|
|
|
I keep getting a comparison failure at line 9 with my implementation that seems perfectly fine. All the internal pins seem to be giving what I need but I think that I need one more clock delay. However, when I try remedy this by adding another register then I get a comparison failure at line 5.
Here is the chip:
CHIP PC {
IN in[16], load, inc, reset;
OUT out[16];
PARTS:
Mux16(a=new, b=in, sel=load, out=out1);
Mux16(a=false, b[1..15]=false, b[0]=true, sel=inc, out=out2);
Add16(a=out1, b=out2, out=out3);
Mux16(a=out3, b=false, sel=reset, out=out4);
Register(in=out4, load=true, out=new, out=out);
}
Any general advice?
By the way, thank you Mark for your help in my other 2 threads, that helped me out a ton.
|
|
Administrator
|
Zebo wrote
I keep getting a comparison failure at line 9 with my implementation that seems perfectly fine. All the internal pins seem to be giving what I need but I think that I need one more clock delay. However, when I try remedy this by adding another register then I get a comparison failure at line 5.
I haven't looked at your HDL in detail, but it looks like you may have a priority problem with load vs. inc. The spec says that if reset is active, load and inc are don't cares. When load is active, inc is don't care.
inc and load might be interacting in the Add16.
--Mark
|
|
|
I have found a solution incorporating an ALU as part of the PC and it came through the test.
I don't know exactly how much of the solution i can give away here.
|
|
Administrator
|
Rather Iffy wrote
I have found a solution incorporating an ALU as part of the PC and it came through the test.
I don't know exactly how much of the solution i can give away here.
For TECS if it passes the tests it's good. TECS encourages encapsulated thinking; and using the ALU to compute what the next state of the PC should be is quite clever.
In general, though, it is easier in hardware to choose things based on control signals than to do conditional computation based on control signals. Think about what chips you've built that let you make choices.
--Mark
|
|
|
cadet1620 wrote
The spec says that if reset is active, load and inc are don't cares. When load is active, inc is don't care.
Firstly, as a self-learner trying to follow TECS, I'd like to say a huge "thank you" to the creators of this forum and to the admins who are helping people like me! I'll try to ask my question without posting spoilers...
I've been trying to follow the advice in this thread, but am still completely stuck on this chip. Cadet's comment above suggests to me that the logic of the circuit needs to be (working from in to out):
In > Increment? > Load? > Reset? > Out
I think I have written my HDL in this way, starting with a Mux16 to select either "in" or "in" passed through the Incrementer chip from Ch2, followed by a Register chip, and finally a Mux16 to select either the previous operations or 0. My comparison fails almost immediately.
Am I on anything near the right lines here please?
|
|
|
You're on the right track!
|
|
|
Thanks for the quick reply, ybakos.
I'll have another look at my HDL for the approach I've been following to see what it is I'm missing here...
|
|
Administrator
|
Tom1984 wrote
In > Increment? > Load? > Reset? > Out
Where in this sequence should the DFF go so that it is affected by all the inputs?
--Mark
|
|
|
I'm still really struggling with this chip, and I wonder if it's because I have misunderstood the notes in the Implementation section:
Counter A w-bit counter consists of two main elements: a regular w-bit register, and combinational logic. (TECS p52)
I'm reading this as saying "the only sequential logic employed here is a single, standard, 16-bit register". But then I'm having trouble seeing how the counter can store the values set by inc and reset, when load only determines whether or not the original input is fed in.
EDIT: If load is a don't care when reset is active, how is "0" fed back into the chip to be repeated / incremented?
cadet1620 wrote
Where in this sequence should the DFF go
Do you mean there needs to be a further DFF/DFFs after the register, Mark?
Thanks
Tom
|
|
Administrator
|
Sorry to confuse you. I meant Register but my traitorous fingers typed DFF.
The PC is similar to the Bit in construction, except that Register replaces the DFF. The combinatorial logic for Bit switches between reloading the DFF output or the input value depending on load.
The PC's combinatorial logic works similarly, but as you have identified, there are more choices.
If you want more explicit help, you can contact me directly via email (More>Reply to author).
--Mark
|
|
|
Got it! :) Thanks for taking the time to help, Mark and ybakos. After sleeping on this, I saw what you were getting at.
I realised how it's possible to use gates created earlier to switch the register's load pin on or off as required, based on the other options that need to be selected.
Tom
|
|
|
Just implemented my PC. This was one of the hardest chips for me so far. It took me a while to understand the DFF and I don't think i fully do. I had the same realization as Tom eventually.
|
|
|
Many thanks for all the advice about the program counter chip (and indeed about the course as a whole, which is fascinating) - it is very helpful to read other people's experiences. I've now got a working version that passes the test cases but I have an uneasy feeling that my solution might be a bit more complicated than totally necessary and that there is a 'right' way of solving this that the authors are trying to guide me towards.
I guess that a good metric for complexity is the number of component parts. My solution uses two 'OR' gates, three 'Mux16' gates, a 'Register' and an 'Inc16'. Is this optimum or should I be looking for a simpler way of doing this?
Many thanks.
|
|
Administrator
|
CaptainBarnacles wrote
I guess that a good metric for complexity is the number of component parts. My solution uses two 'OR' gates, three 'Mux16' gates, a 'Register' and an 'Inc16'. Is this optimum or should I be looking for a simpler way of doing this?
Your solution is good. There are some some things that can make it a bit better, but don't spend time trying to optimize it now. I recommend that you finish the logic part of the book (chapters 1-5) and then go back to look at your earlier circuits and you will likely see ways to improve them.
For the PC, the first question is "Do I really need logic to control the load input to the Register?"
If you want to, send me your PC.hdl and I'll send you a collection of various implementations.
--Mark
|
|
|
marvellous, I'll carry on through the first five chapters and see how I get on. Thank you.
I'm finding this course most interesting - I worked through the Petzold 'Code' book a few years ago but while I felt I understood the text (and I do recommend his book), I struggled to really 'get it' - now with the TECS book, by doing the hands-on construction, I'm really beginning to grasp the fundamental leap of imagination from gates to software which has always eluded me.
|
|
|
Thanks alot every one in this Post
seriously the PC chip was the most difficult to be implemented
it took me 2 days trying to figure out how to store the value and reuse it
and finally i realized the post mentioned by Zebo
that i can use the output of a register as an input to the same chip
Mux16(a=new, b=in, sel=load, out=out1);
Register(in=out4, load=true, out=new, out=out);
after i figured how to use the output as the input the rest is simple
just followed the rules mentioned in the chip
increment > Load > reset
so i first increment and Mux it
then Load and Mux it
last i Reset and Mux it
finally use the ORs to
Or(a=inc, b=load, out=l1);
Or(a=l1,b=reset, out=l2);
before Register the final result
hope it enlightens new students
Thanks all again
|
|
|
WHEW... got it... Just the RAM chips left in the b folder and I can move on!
Thanks Ammarr, these words made the "light" go on insight my head... a joyous feeling.
increment > Load > reset
so i first increment and Mux it
then Load and Mux it
last i Reset and Mux it
That gave me the insight that I would need to reverse the pin arrangements (work from inside the nested if statements and out). Forcing my brain to stop thinking procedurally is not easy.
But guys... there's no need for the OR chips.
|
|
|
Here is an outline of how I designed the PC without any OR chips. I hope this doesn't give away too much.
PC_outline.JPG
|
|
|
cadet1620 wrote
I haven't looked at your HDL in detail, but it looks like you may have a priority problem with load vs. inc. The spec says that if reset is active, load and inc are don't cares. When load is active, inc is don't care.
inc and load might be interacting in the Add16.
--Mark
best advice.. took 2 min once I saw this quote.. worked on it for an hour and it kept failing at different test numbers, saw this changed my mux order and worked first time..
|
|
Locked
