The symptom occurs in the screen write. The way it looked was that the screen was correct except that what was being displayed was being slowly scrolled to the bottom... as though the screens base address was being indexed by 320, (NTSC,320x240, gray). SO... it appears that occasionally, when I index the line to the next line... somehow that index is being applied to the screen's base address.
This doesn't happen right away... it takes several hours for it to show up. Today, I started the P2 working, went to 5 different locations 60 miles apart hunting for frogs. I finally found a frog, went home, cleaned the old tank, scrubbed the refrigerator and finally sat down to check in and the screen was just beginning to scroll. It doesn't wrap:) when it gets to the bottom it then just fills the screen with what look to be alien transmissions. One variable getting indexed wrong after hundreds of thousands of correct values. I'm glad you understand it:)
The question is: Is that a software or hardware bug?
It sounds like 32-bit fractions accumulating (ie $5555_5555 = 1/3) and then once in a while an extra clock is taken because a rollover didn't occur on the usual Nth clock.
But to answer your question more completely after thinking about it...
I don't know.
We are talking about a stereo acquisition and display... Both cogs use exactly the same code but depending upon their COGID, take different nibs from INA and write to two different place on the screen. So... this could be a simple scoping issue, which should never have worked but I got away with due to luck. I can imagine, but really just barely... that what I am seeing is a scoping error that popped up because the new cog attention synchronization revealed the fact that I was breaking the scope.
To complicate matters, while I am using 320x240 NTSC, in fact, the top of my image is off the screen.
The effect is very slow... I don't remember how many lines are off the screen at the top... so the whole thing could have been there the whole time and because of my work habits, I just didn't notice... since except at night, when the P2 is on I am working on the software and the time between test runs is fairly short.
The only place that I can think that a roll-over issue might crop up is in the video generation... makes no sense to me, but then I have fairly superficial understanding of the driver.
The only place that I can think that a roll-over issue might crop up is in the video generation... makes no sense to me, but then I have fairly superficial understanding of the driver.
I've been working on getting all the flops to have asynchronous resets, so that we can have scan insertion done during synthesis. It doesn't cost anything to synthesize with these special flops which form a giant shift register when in TEST mode (pin 1 of the Prop2 is TESn). Only when you have a test program made to exercise the scan chain with test patterns, do you need to spend a bunch of money. This scan insertion is a way to test out the chip's logic after manufacturing, to be sure that there are no defects.
Anyway, it's proceeding well, but now I'm moving into the cog, which has been using an asynchronous reset, all along, to keep it shut down when it's not in use. That shut-down signal needs to become synchronous, instead, so that the scan chain can use the asynchronous reset.
I've been thinking about how to do this for months, and it's just not clear to me. It sounds simple, but it disrupts the way things have been working since day one. Tomorrow, when I'm fresh, I'll get into this. This is the last edit I know I need to make to the Verilog.
Once this is done, we can synthesize a chip at any time. We'll just need to be sure that the design is good.
If MRAM becomes an option at some stage then it'll be a big improvement over all alternatives simply because it replaces all HubRAM and with lots of room to spare. 1MB will be a breeze.
If they can't do flash or eeprom, can they do OTP cells?
Then a single fuse bit could choose normal boot or OTP boot...
They likely can do all of those, but it comes down to IP cost, added mask costs, possible Vpp pins, and existing design decisions.
Presently I think Chip has selected a custom literal-fuse design that is in the PAD Ring area.
This uses a high current to force a change.
This should be testable in the shuttle run, and may impose some power supply constraints for Fuse-set that are tighter than operate.
If that all works 100%, it may be possible to keep those literal fuses, and simply swap ROM for OTP (or MTP ?) - that comes down to the relative area, including support.
Even with OTP, some means to program that OTP is needed, which points to some ROM still being required (or a JTAG like path on the Chip tester).
I've been working on getting all the register assignments changed around so that we can do scan test insertion. This entails using a text macro within all Verilog files that had used an ALWAYS construct.
Here is the macro:
`define regscan(regname, reginit, regcond, regval) \
always @(posedge clk or negedge resn) \
if (!resn) \
regname <= reginit; \
else if (regcond) \
regname <= regval;
What used to look like this:
always @(posedge clk)
if (ena)
timeout <= got_cnt;
Now gets retyped into this:
`regscan (timeout, 1'b0, ena, got_cnt)
I've been working backwards into the main cog Verilog file. It's the only one I have left to do, and I'll be working on it tomorrow.
After that, barring any bugs that may be discovered, we'll have fully synthesizable code for making final chips.
I've been working on getting all the register assignments changed around so that we can do scan test insertion. This entails using a text macro within all Verilog files that had used an ALWAYS construct.
Here is the macro:
`define regscan(regname, reginit, regcond, regval) \
always @(posedge clk or negedge resn) \
if (!resn) \
regname <= reginit; \
else if (regcond) \
regname <= regval;
What used to look like this:
always @(posedge clk)
if (ena)
timeout <= got_cnt;
Now gets retyped into this:
`regscan (timeout, 1'b0, ena, got_cnt)
I've been working backwards into the main cog Verilog file. It's the only one I have left to do, and I'll be working on it tomorrow.
After that, barring any bugs that may be discovered, we'll have fully synthesizable code for making final chips.
Chip, I am but a lowly Moderator, and I read each and every post put on this forum. I applaud all the work you have done and applaud every forum member for their contributions to the next great Propeller chip.
What ever happened to the May shuttle? Did the P2 test make it?
It's being fabricated now. It's all the analog stuff involving the pad frame. There is no synthesized core logic. We're just interested in proving the pins, at this point.
What ever happened to the May shuttle? Did the P2 test make it?
It's being fabricated now. It's all the analog stuff involving the pad frame. There is no synthesized core logic. We're just interested in proving the pins, at this point.
Sounds like an important step forward though. When do you expect to get chips?
Did you manage to get anywhere with the BeMicroCV-A9? I've had a few too many things on my plate to sort out any details but I think Chip said he would do an image for it, he just needs a pinout.
Did you manage to get anywhere with the BeMicroCV-A9? I've had a few too many things on my plate to sort out any details but I think Chip said he would do an image for it, he just needs a pinout.
What ever happened to the May shuttle? Did the P2 test make it?
It's being fabricated now. It's all the analog stuff involving the pad frame. There is no synthesized core logic. We're just interested in proving the pins, at this point.
Sounds like an important step forward though. When do you expect to get chips?
I've been working on getting all the register assignments changed around so that we can do scan test insertion. This entails using a text macro within all Verilog files that had used an ALWAYS construct.
Here is the macro:
`define regscan(regname, reginit, regcond, regval) \
always @(posedge clk or negedge resn) \
if (!resn) \
regname <= reginit; \
else if (regcond) \
regname <= regval;
What used to look like this:
always @(posedge clk)
if (ena)
timeout <= got_cnt;
Now gets retyped into this:
`regscan (timeout, 1'b0, ena, got_cnt)
I've been working backwards into the main cog Verilog file. It's the only one I have left to do, and I'll be working on it tomorrow.
After that, barring any bugs that may be discovered, we'll have fully synthesizable code for making final chips.
Chip, I am but a lowly Moderator, and I read each and every post put on this forum. I applaud all the work you have done and applaud every forum member for their contributions to the next great Propeller chip.
There is light at the end of the tunnel!
Yes. The end of the tunnel is close.
I'm really glad that there's interest among forum members for making different tools. I'll be 50 next year and I'm sensing my limits.
Comments
The question is: Is that a software or hardware bug?
It sounds like 32-bit fractions accumulating (ie $5555_5555 = 1/3) and then once in a while an extra clock is taken because a rollover didn't occur on the usual Nth clock.
I don't know.
We are talking about a stereo acquisition and display... Both cogs use exactly the same code but depending upon their COGID, take different nibs from INA and write to two different place on the screen. So... this could be a simple scoping issue, which should never have worked but I got away with due to luck. I can imagine, but really just barely... that what I am seeing is a scoping error that popped up because the new cog attention synchronization revealed the fact that I was breaking the scope.
To complicate matters, while I am using 320x240 NTSC, in fact, the top of my image is off the screen.
The effect is very slow... I don't remember how many lines are off the screen at the top... so the whole thing could have been there the whole time and because of my work habits, I just didn't notice... since except at night, when the P2 is on I am working on the software and the time between test runs is fairly short.
I'll chew on it tomorrow afternoon.
I hope it is me:)
It would be great to know what's causing it.
Are you generating NTSC or VGA?
Anyway, it's proceeding well, but now I'm moving into the cog, which has been using an asynchronous reset, all along, to keep it shut down when it's not in use. That shut-down signal needs to become synchronous, instead, so that the scan chain can use the asynchronous reset.
I've been thinking about how to do this for months, and it's just not clear to me. It sounds simple, but it disrupts the way things have been working since day one. Tomorrow, when I'm fresh, I'll get into this. This is the last edit I know I need to make to the Verilog.
Once this is done, we can synthesize a chip at any time. We'll just need to be sure that the design is good.
I forgot to! I will ask them tomorrow.
If MRAM becomes an option at some stage then it'll be a big improvement over all alternatives simply because it replaces all HubRAM and with lots of room to spare. 1MB will be a breeze.
Then a single fuse bit could choose normal boot or OTP boot...
Presently I think Chip has selected a custom literal-fuse design that is in the PAD Ring area.
This uses a high current to force a change.
This should be testable in the shuttle run, and may impose some power supply constraints for Fuse-set that are tighter than operate.
If that all works 100%, it may be possible to keep those literal fuses, and simply swap ROM for OTP (or MTP ?) - that comes down to the relative area, including support.
Even with OTP, some means to program that OTP is needed, which points to some ROM still being required (or a JTAG like path on the Chip tester).
Here is the macro:
What used to look like this:
Now gets retyped into this:
I've been working backwards into the main cog Verilog file. It's the only one I have left to do, and I'll be working on it tomorrow.
After that, barring any bugs that may be discovered, we'll have fully synthesizable code for making final chips.
re:After that, barring any bugs that may be discovered, we'll have fully synthesizable code for making final chips.
Great!! Chip, that's music to my ear's
Wow Chip, that's pretty exciting!
What does this do to the LUT count ?
Do you need to apply this to every single register, even those in FIFOs ?
Chip, I am but a lowly Moderator, and I read each and every post put on this forum. I applaud all the work you have done and applaud every forum member for their contributions to the next great Propeller chip.
There is light at the end of the tunnel!
It's being fabricated now. It's all the analog stuff involving the pad frame. There is no synthesized core logic. We're just interested in proving the pins, at this point.
Did you manage to get anywhere with the BeMicroCV-A9? I've had a few too many things on my plate to sort out any details but I think Chip said he would do an image for it, he just needs a pinout.
Every single flop gets this attention and receives a global asynchronous reset signal. It added some logic, but only about 1%.
I just need a pin out for it.
Probably end of July.
Yes. The end of the tunnel is close.
I'm really glad that there's interest among forum members for making different tools. I'll be 50 next year and I'm sensing my limits.
I'm recompiling the Prop123-A9 version now. It should take a few hours.
Is there a kind of Quickstart board in the works so that it is possible to buy a dev board as soon as you get chips?