Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i

15051535556160

Comments

  • rjo__ wrote: »
    In the for what it is worth department.

    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.
  • I'll time it. Not there right now. Libby is in town and with the way she rolls around at night I have retreated to my hole.
  • AND she doesn't allow smoking.
  • rjo__rjo__ Posts: 2,080
    edited 2016-06-08 - 07:16:15
    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.

    I'll chew on it tomorrow afternoon.

    I hope it is me:)

  • 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.
  • rjo__ wrote: »
    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.

    It would be great to know what's causing it.

    Are you generating NTSC or VGA?
  • cgraceycgracey Posts: 12,799
    edited 2016-06-08 - 08:15:44
    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.
  • Cluso99 wrote: »
    Chip,
    Did you ask about Flash or Eeprom?

    I forgot to! I will ask them tomorrow.
  • Win10 lets me download now. Guess they finally figured out that pnut isn't a virus...
  • cgracey wrote: »
    Cluso99 wrote: »
    Chip,
    Did you ask about Flash or Eeprom?

    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.
  • 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...
    cgracey wrote: »
    Cluso99 wrote: »
    Chip,
    Did you ask about Flash or Eeprom?

    I forgot to! I will ask them tomorrow.

  • jmgjmg Posts: 14,321
    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).
  • cgraceycgracey Posts: 12,799
    edited 2016-06-14 - 07:27:33
    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.
  • re:cgracey

    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 :)
  • cgracey wrote: »
    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.

    Wow Chip, that's pretty exciting!
  • What ever happened to the May shuttle? Did the P2 test make it?
  • jmgjmg Posts: 14,321
    cgracey wrote: »
    I've been working on getting all the register assignments changed around so that we can do scan test insertion.

    What does this do to the LUT count ?
    Do you need to apply this to every single register, even those in FIFOs ?

  • cgracey wrote: »
    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!



  • Cannot wait to see real silicon :)
  • In the meantime it is fascinating to see a neglected BeMicro-A2 come to life and do something useful.
  • David Betz wrote: »
    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.
  • cgracey wrote: »
    David Betz wrote: »
    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?

  • Cluso99 wrote: »
    Cannot wait to see real silicon :)

    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.
  • jmg wrote: »
    cgracey wrote: »
    I've been working on getting all the register assignments changed around so that we can do scan test insertion.

    What does this do to the LUT count ?
    Do you need to apply this to every single register, even those in FIFOs ?

    Every single flop gets this attention and receives a global asynchronous reset signal. It added some logic, but only about 1%.
  • Cluso99 wrote: »
    Cannot wait to see real silicon :)

    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.

    I just need a pin out for it.
  • David Betz wrote: »
    cgracey wrote: »
    David Betz wrote: »
    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?

    Probably end of July.
  • Publison wrote: »
    cgracey wrote: »
    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.
  • Okay. I got all the registers recoded for scan insertion. Everything works and I double-checked my edits.

    I'm recompiling the Prop123-A9 version now. It should take a few hours.
  • cgracey wrote: »
    Probably end of July.

    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?
  • David BetzDavid Betz Posts: 13,979
    edited 2016-06-15 - 12:33:18
    FredBlais wrote: »
    cgracey wrote: »
    Probably end of July.

    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?
    These are test chips for verifying the analog parts of the pins. They aren't chips we could make use of.

Sign In or Register to comment.