Shop OBEX P1 Docs P2 Docs Learn Events
Here is the update from the Big Change!!! — Parallax Forums

Here is the update from the Big Change!!!

cgraceycgracey Posts: 14,134
edited 2013-12-05 18:51 in Propeller 2
Here is the update from the Big Change:

=== NEW FILE ON 11/27/2013 ===

Terasic_Prop2_Emulation_2013_11_27.zip

This will work with the DE0-Nano and DE2-115 boards that some of you have, along with the adapter boards we sent out.

A lot of specifics have changed regarding configuration registers. Be sure to review any sections of Prop2_Docs.txt that relate to your programs. There are several demonstration programs in the .zip that generate video. Balls.spin incorporates a callable SDRAM driver that uses the cog's AUX RAM, instead of the QUADs - so it can run on the DE0-Nano.

It's taking me several compiler runs, lately, before I get a fast-enough DE0-Nano compilation out of Quartus II (the Altera FPGA tool). I had to adjust some fitting options before it would even fit, at all. Now a one-cog compilation is taking 99.65% of the DE0-Nano FPGA's logic elements.

Thanks for your patience. Now I'm making some transistor-size changes for Beau to work on...
«13456

Comments

  • jmgjmg Posts: 15,171
    edited 2013-11-25 09:47
    cgracey wrote: »
    It's taking me several compiler runs, lately, before I get a fast-enough DE0-Nano compilation out of Quartus II (the Altera FPGA tool). I had to adjust some fitting options before it would even fit, at all. Now a one-cog compilation is taking 99.65% of the DE0-Nano FPGA's logic elements.

    Does that mean the DE0-Nano now has a different max MHz than DE2-115 ?
    What is the newest build's target fMAX for each device ?
  • David BetzDavid Betz Posts: 14,516
    edited 2013-11-25 09:51
    Cool! Thanks for the update!
  • potatoheadpotatohead Posts: 10,261
    edited 2013-11-25 10:16
    Thanks Chip! You made it in time for Turkey day.

    Can't wait to jump in. :)
  • cgraceycgracey Posts: 14,134
    edited 2013-11-25 10:21
    jmg wrote: »
    Does that mean the DE0-Nano now has a different max MHz than DE2-115 ?
    What is the newest build's target fMAX for each device ?

    They are both still good at 80MHz. Quartus reported Fmax values of 74MHz for the DE2-115 compilation and 67MHz for the DE0-Nano compilation, but those are worst-case conditions, which none of us are going to have at our workbenches. Both the 5-cog DE2-115 and 1-cog DE0-Nano are being clocked at 80MHz. I've seen flakey behavior at 80MHz when Quartus reports an Fmax of around 60MHz. For what we are all doing now, this overclocking is not an issue. When we spec the Fmax of the actual chip, it will be based on worst-case simulation, backed up by real device testing.
  • Bill HenningBill Henning Posts: 6,445
    edited 2013-11-25 10:25
    Excellent!!! THANKS!

    Now to read the new docs, and re-load my nano and de2-115...
    cgracey wrote: »
    Here is the update from the Big Change:

    Attachment not found.

    This will work with the DE0-Nano and DE2-115 boards that some of you have, along with the adapter boards we sent out.

    A lot of specifics have changed regarding configuration registers. Be sure to review any sections of Prop2_Docs.txt that relate to your programs. There are several demonstration programs in the .zip that generate video. Balls.spin incorporates a callable SDRAM driver that uses the cog's AUX RAM, instead of the QUADs - so it can run on the DE0-Nano.

    It's taking me several compiler runs, lately, before I get a fast-enough DE0-Nano compilation out of Quartus II (the Altera FPGA tool). I had to adjust some fitting options before it would even fit, at all. Now a one-cog compilation is taking 99.65% of the DE0-Nano FPGA's logic elements.

    Thanks for your patience. Now I'm making some transistor-size changes for Beau to work on...
  • SapiehaSapieha Posts: 2,964
    edited 2013-11-25 10:28
    Hi Chip.

    Nice update

    Else I'm still not found it ---

    But I'm still are missing SERTEST --- check if character waiting?
  • cgraceycgracey Posts: 14,134
    edited 2013-11-25 10:31
    Sapieha wrote: »
    Hi Chip.

    Nice update

    Else I'm still not found it ---

    But I'm still are missing SERTEST --- check if character waiting?

    Use 'SERINA D WC' or SERINB D WC'. They will release immediately (1-clock) and if C=1 afterwards, then D is holding what came in.
  • SapiehaSapieha Posts: 2,964
    edited 2013-11-25 10:33
    Hi Chip.

    Thanks
  • nutsonnutson Posts: 242
    edited 2013-11-25 11:09
    The DE2-115 demo's I have tried (VGA and NTSC) are working fine. The balls demo is amazing. Thanks for this great update!!

    Nico Hattink
  • cgraceycgracey Posts: 14,134
    edited 2013-11-25 11:28
    nutson wrote: »
    The DE2-115 demo's I have tried (VGA and NTSC) are working fine. The balls demo is amazing. Thanks for this great update!!

    Nico Hattink

    In balls.spin, if you change that one pushbutton symbol to 31 for the DE2-115, you can use the left-most pushbutton to freeze the animation. I was just playing around with the new pixel-blending instructions when I made that program, based on the prior color swirler. Roy Eltham taught me the sum-of-products equation that does all the pixel-level effects. It's pretty simple stuff, but when applied it gives very natural, quite photographic effects. By adding some noise from GETLFSR to the balls' colors, then blending towards white, you can plainly see the rough surface of the balls as the light reflects off them. You need to freeze the animation to observe this most clearly, though. It looks like a photograph, to me, and was it all quite accidental.
  • rjo__rjo__ Posts: 2,114
    edited 2013-11-25 11:34
    Christmas came early!!!

    Thank you very much.
  • nutsonnutson Posts: 242
    edited 2013-11-25 11:42
    The DE0-nano is working too. Stopping the animation indeed shows the very natural looking surface irregularities. Like over-used and mistreated snooker balls.Fun!
  • User NameUser Name Posts: 1,451
    edited 2013-11-25 12:06
    potatohead wrote: »
    Thanks Chip! You made it in time for Turkey day.

    Seriously. What great timing!!

    I love the 99.65% aspect. May as well get full value out of the little thing. :)
  • Ken GraceyKen Gracey Posts: 7,390
    edited 2013-11-25 12:21
    I'm working on getting the DE2-115s in stock, along with our adapter board.

    Ken Gracey
  • jmgjmg Posts: 15,171
    edited 2013-11-25 12:38
    Ken Gracey wrote: »
    I'm working on getting the DE2-115s in stock, along with our adapter board.

    Good idea.

    When Chip heads home, he could maybe run a Quartus build on the New BeMicro CV = Cyclone V (5CEFA2F23C8N), to see what numbers that gives.

    This was showing at $42 @ Verical, but seems to be cleaned out at the moment.

    add: and this was mentioned too

    http://www.altera.com/products/devkits/altera/kit-terasic-cyclone-v-gx-starter.html
    Cyclone V GX 5CGXFC5C6F27C7N ( shows stock (2013-12-27) )
    Maybe 3 COGs ?
  • SeairthSeairth Posts: 2,474
    edited 2013-11-25 12:40
    Argh! I'm stuck in an airport for 6 hours! Someone post a picture of the balls, so I can see what you all are talking about!
  • cgraceycgracey Posts: 14,134
    edited 2013-11-25 13:13
    Seairth wrote: »
    Argh! I'm stuck in an airport for 6 hours! Someone post a picture of the balls, so I can see what you all are talking about!

    I tried to take one, but the camera just saturated the red, green, and blue, and it didn't do it justice, at all. What we need, somehow, is an actual 24bpp image made into a .bmp.
  • nutsonnutson Posts: 242
    edited 2013-11-25 13:16
    It took some time, my camera simply refuses to autofocus on the LCD screen.
    1024 x 768 - 74K
  • SeairthSeairth Posts: 2,474
    edited 2013-11-25 13:43
    Thanks! That looks awesome! I see a new version of Hydra in the near future...
  • BaggersBaggers Posts: 3,019
    edited 2013-11-25 15:12
    Awesome update Chip :D just off to bed now so won't be able to test until tomorrow!

    nutson, thanks for sharing a pic :) looks awesome!

    Can't wait to see the demo Chip!

    PS, Chip, I'll let you know if the update works.
    Cheers,
    Jim.
  • potatoheadpotatohead Posts: 10,261
    edited 2013-11-25 15:15
    With this VGA / HDTV timing, we won't be able to capture easily anymore. Well, we can generally move the display to composite, S-Video, but it won't look good. Prototyping only, IMHO.

    (Unless it's intended for TV resolution)

    What we need to do is stream the pixels out to the SDRAM or something for a frame capture. Like JTCook did on HYDRA for VGA back in the day.
  • ozpropdevozpropdev Posts: 2,792
    edited 2013-11-25 15:28
    :)Thanks Chip! :)
  • rjo__rjo__ Posts: 2,114
    edited 2013-11-25 15:52
    Ken!!!!!!!
  • Cluso99Cluso99 Posts: 18,069
    edited 2013-11-25 16:41
    Thanks Chip.
    Those balls look amazing (thanks for the pic nutson)

    Looks like us DE0 users will be getting a reduced cog implementation shortly :(
    What can be left out???

    BTW I noticed in the docs...

    COGNEW D, S/#
    you say S is only 17 bits and is stored in PTRA. Couldn't/isn't this a full 32 bits?

    Seems to imply port pins 92..95 are not internally connected like 96..127. Is this correct?
  • jmgjmg Posts: 15,171
    edited 2013-11-25 16:43
    --- check if character waiting?
    cgracey wrote: »
    Use 'SERINA D WC' or SERINB D WC'. They will release immediately (1-clock) and if C=1 afterwards, then D is holding what came in.

    Nice detail.

    Where does this leave details on other serial support like SPI/QSPI/I2S etc, and P2 Counter documentation ?
    Is this a final pass, or an interim one, with Serial to come ?

    Counter docs would allow some field testing and mode coverage checking.
  • cgraceycgracey Posts: 14,134
    edited 2013-11-25 16:46
    potatohead wrote: »
    With this VGA / HDTV timing, we won't be able to capture easily anymore. Well, we can generally move the display to composite, S-Video, but it won't look good. Prototyping only, IMHO.

    (Unless it's intended for TV resolution)

    What we need to do is stream the pixels out to the SDRAM or something for a frame capture. Like JTCook did on HYDRA for VGA back in the day.

    I used the SEROUTA instruction to send the data back to the PC via the PropPlug, and had the PNut.exe program capture it to a bitmap, which got saved into a file:

    balls.png


    At first, I was having all kinds of problems. It turns out that the FTDI driver doesn't receive 2M baud correctly. I had to switch down to 1M baud.
    640 x 480 - 667K
  • jmgjmg Posts: 15,171
    edited 2013-11-25 16:59
    balls.bmp link coughs ? ( now fixed)

    The FTDI parts can loop-back at 2MBd, but they are adding extra stop bits at those high baud rates, so sustained send from something like a P2 into a FS FTDI, is tougher, and will likely have issues, as you found.
    How many stop bits did you use ?

    Be interesting to see how a FT232H/FT2232H copes with sustained sending at even higher baud speeds.
    (and even in Fast Serial mode, which claims <= 50MHz bit rates, but that needs a CLK from P2 => 'clocked async' )
  • cgraceycgracey Posts: 14,134
    edited 2013-11-25 17:01
    Cluso99 wrote: »
    Thanks Chip.
    Those balls look amazing (thanks for the pic nutson)

    Looks like us DE0 users will be getting a reduced cog implementation shortly :(
    What can be left out???

    BTW I noticed in the docs...

    COGNEW D, S/#
    you say S is only 17 bits and is stored in PTRA. Couldn't/isn't this a full 32 bits?

    Seems to imply port pins 92..95 are not internally connected like 96..127. Is this correct?

    PTRA and PTRB are both 17 bits. So, even though you can express 32 bits in S, after it gets written into PTRA, it's only 17 bits. I used to have PTRA and PTRB at 32 bits, even though only the 17 bottom bits were used (max hub address of $1FFFF), but it was a critical path that stuck out like a sore thumb, as PTRx addressing has to get resolved in a fraction of a cycle.

    Pins 92..95 don't do anything and read '0'. We could make them read something else, of course. Pins 96..127 are the inter-cog I/O's which also connect to ALL the peripherals, so they are available for all kinds of applications inside the chip.
  • cgraceycgracey Posts: 14,134
    edited 2013-11-25 17:06
    jmg wrote: »
    balls.bmp link coughs ? ( now fixed)

    The FTDI parts can loop-back at 2MBd, but they are adding extra stop bits at those high baud rates, so sustained send from something like a P2 into a FS FTDI, is tougher, and will likely have issues, as you found.
    How many stop bits did you use ?

    Be interesting to see how a FT232H/FT2232H copes with sustained sending at even higher baud speeds.
    (and even in Fast Serial mode, which claims <= 50MHz bit rates, but that needs a CLK from P2 => 'clocked async' )

    The SERA/SERB do just 1 stop bit. That explains the problem I was having. I never thought 1 wouldn't be enough for some receiver. I could add an extra stop bit, but I'm out of config bits now. Also, I haven't gotten into what the SERDES is going to do, so there will probably be a lot of changes, the stop bit being among the least.
  • jmgjmg Posts: 15,171
    edited 2013-11-25 17:25
    cgracey wrote: »
    The SERA/SERB do just 1 stop bit. That explains the problem I was having. I never thought 1 wouldn't be enough for some receiver. I could add an extra stop bit, but I'm out of config bits now. Also, I haven't gotten into what the SERDES is going to do, so there will probably be a lot of changes, the stop bit being among the least.

    Being able to define stop bits will be useful, but an alternative way to manage that, is to allow a granularity of 1 on bit-length.
    Then, users can define any number of stop bits (up to frame max of 32b?) via a small SW overhead.
Sign In or Register to comment.