Shop OBEX P1 Docs P2 Docs Learn Events
The New 16-Cog, 512KB, 64 analog I/O Propeller Chip - Part 2 - Page 2 — Parallax Forums

The New 16-Cog, 512KB, 64 analog I/O Propeller Chip - Part 2

2456719

Comments

  • evanhevanh Posts: 15,915
    edited 2015-09-07 09:27
    Cluso99 wrote: »
    logic area interior 42.2 - memories 31.6 = 10.6 mm2 for logic

    gates allowance 120k/mm2 x 0.65 utilization x 10.6 mm2 = 827k gates
    If the space used by the gates is only 50% then there would be ~5mm2 remaining.

    Hehe, probably can't assume all square millimetres will be usable. Busses in particular aren't accounted for. The I/O ring bus in the first incarnation of the P2-Hot was extremely real-estate consuming.

    Of course there is a minor change to the hubexec memory model such that these Extended Cog RAM (LUT) addresses are read from the LUT, not the hub/cache.

    Using the LUT as instruction space is certainly an intriguing idea though. It somewhat reduces the need for 512 Cog addresses. Self modifying would be a no-go but I guess that's not so important now.
  • The idea of extending the cog RAM has been proposed many times in the past. There have been several variations on how this would be done, and some were very similar to the idea of using the LUT to extend the memory. All of those ideas have been rejected, and I'm not sure why it makes sense to dredge them up again. It seems like it would be more productive to encourage Chip to finish the design that he decided on so that we can get some time working with the FPGA image before it is frozen in silicon.
  • evanhevanh Posts: 15,915
    Agreed.
  • koehlerkoehler Posts: 598
    edited 2015-09-08 05:41
    Agreed, since previous mention of skipping Cores wouldn't increase bandwidth much if any, and might require h/w change.

    If P3 is ever green-lit, that 2KB limit has to be fixed. IIUC, even the current Hubexec will not run deterministically as the Core ram. Or, it may be fine, with Core ram being actually limited to drivers and larger Hubexec programs being non-deterministic on a fine grain scale?

    Definately time to stop the feature creep, no matter how attractive/simple they look at first blush.
  • cgraceycgracey Posts: 14,152
    I got the last of the block-r/w instructions done tonight: SETQ2+RDLONG ---> Hub to LUT.

    I just added a 'define/ifdef' switch into all the appropriate Verilog files so that Treehouse can do full-logic synthesis, incorporating OnSemi's memory blocks into our logic. This should give us an idea of timing and area.

    I've been working 21 hours, so I'll get a little rest now.
  • That's great news. So the FPGA image is coming soon, right? :)

    What's the binary value for the SETQ2 instruction? Does SETQ2 just set a flag to indicate that RDLONG goes to the LUT instead of cog RAM, or is there now a Q2 register in addition to a Q register?
  • cgracey wrote: »
    I've been working 21 hours, so I'll get a little rest now.
    Dave Hein wrote: »
    That's great news. So the FPGA image is coming soon, right? :)

    What's the binary value for the SETQ2 instruction? Does SETQ2 just set a flag to indicate that RDLONG goes to the LUT instead of cog RAM, or is there now a Q2 register in addition to a Q register?

    What? *only* 21 hours! Hey Chip, do you get the sense that Dave is a hard taskmaster and slave-driver :)

  • Working for the past 21 hours is even more impressive considering that yesterday was a U.S. holiday, and most people were off from work. I'm hoping that Chip is enjoying some much needed sleep right now.
  • That's what I noticed about self-employment, My boss was such a jerk!
  • kwinnkwinn Posts: 8,697
    rabaggett wrote: »
    That's what I noticed about self-employment, My boss was such a jerk!

    I noticed that as well. Seems the bosses (aka customers) are hard task masters.
  • Cluso99Cluso99 Posts: 18,069
    The SETQ2 instruction will set the number of longs to transfer on the next rdlong instruction and it will be hub to lut.
    ie just like the SETQ (or is it SETQ1) does for hub to/from cog with the following rd/wrlong instruction.
  • cgraceycgracey Posts: 14,152
    KMyers wrote: »
    Sounds like good progress! When will the new Parallax board be sold?

    Ken told me today that the new Prop 1-2-3 FPGA Cyclone V -A9 boards are going onto the pick-and-place this week. So, very soon.

    We talked about what we'll sell them for. These boards are expensive to make and we don't believe we can sell them profitably, but that's okay, because they are a necessary component of our development effort. They need to be affordable to those who are interested in the Prop2 and future projects. So, here are our prices to you:

    Prop 1-2-3 FPGA Cyclone V -A9 board: $475.00
    Prop 1-2-3 FPGA Cyclone V -A7 board: $375.00

    We didn't get any special pricing for the -A9, so our production cost on that is just under $400. The -A7 board cost us a little under $300 to make, because we got a deal from Altera on those chips. For the -A9 board, we just needed to get things rolling, so we didn't venture into any protracted pricing effort with Altera. We just bought the chips from Digi-Key. We had Daniel working on this board for almost a year, so there's lot's of sunk costs. At the moment, I'm still using the Terasic DE2-115 board because I haven't wanted the upset of switching everything over just yet. I'll be moving the -A7 board shortly, and then the -A9.

    Anyway, that's the scoop on the new FPGA board. The loader on it is way faster than the Altera arrangement that all other boards seem to use.

    Ken said that seven of you have bought the -A7 boards. Can you report on this thread how they're working out, so far?
  • jmgjmg Posts: 15,173
    cgracey wrote: »
    Ken told me today that the new Prop 1-2-3 FPGA Cyclone V -A9 boards are going onto the pick-and-place this week. So, very soon.
    ...For the -A9 board, we just needed to get things rolling, so we didn't venture into any protracted pricing effort with Altera. We just bought the chips from Digi-Key.

    How many -A9 are being built ?

    Do you have BeMicro CV A9 boards there to test ?

    ( Of course, that's another way to buy A9 parts, if you can find a friendly re-ball company )

  • cgracey wrote: »
    KMyers wrote: »
    Sounds like good progress! When will the new Parallax board be sold?

    Ken told me today that the new Prop 1-2-3 FPGA Cyclone V -A9 boards are going onto the pick-and-place this week. So, very soon.

    We talked about what we'll sell them for. These boards are expensive to make and we don't believe we can sell them profitably, but that's okay, because they are a necessary component of our development effort. They need to be affordable to those who are interested in the Prop2 and future projects. So, here are our prices to you:

    Prop 1-2-3 FPGA Cyclone V -A9 board: $475.00
    Prop 1-2-3 FPGA Cyclone V -A7 board: $375.00

    We didn't get any special pricing for the -A9, so our production cost on that is just under $400. The -A7 board cost us a little under $300 to make, because we got a deal from Altera on those chips. For the -A9 board, we just needed to get things rolling, so we didn't venture into any protracted pricing effort with Altera. We just bought the chips from Digi-Key. We had Daniel working on this board for almost a year, so there's lot's of sunk costs. At the moment, I'm still using the Terasic DE2-115 board because I haven't wanted the upset of switching everything over just yet. I'll be moving the -A7 board shortly, and then the -A9.

    Anyway, that's the scoop on the new FPGA board. The loader on it is way faster than the Altera arrangement that all other boards seem to use.

    Ken said that seven of you have bought the -A7 boards. Can you report on this thread how they're working out, so far?
    The $475 price sounds good. When will it be possible to place an order? Also, is the source available for the programming tool?
  • cgraceycgracey Posts: 14,152
    Dave Hein wrote: »
    That's great news. So the FPGA image is coming soon, right? :)

    What's the binary value for the SETQ2 instruction? Does SETQ2 just set a flag to indicate that RDLONG goes to the LUT instead of cog RAM, or is there now a Q2 register in addition to a Q register?

    They both write the same register. There are flops that record which one was used.

    I've started writing the docs in Google Docs, so I'll be able to start sharing it soon. It's quite a shift to write documentation.

    That idea about using the LUT as an instruction source might be very trivial to implement. It would just kick in for PC addresses $200..$2FF (times 4, of course). I'm thinking about it, anyway. It might only be a 32-bit mux for data and an 8-bit mux for address to the LUT. We really should boost that thing to 512 longs, though, to do this. Okay, nobody go ape-snarf.
  • Cluso99Cluso99 Posts: 18,069
    edited 2015-09-09 01:46
    "cgracey wrote: »
    That idea about using the LUT as an instruction source might be very trivial to implement. It would just kick in for PC addresses $200..$2FF (times 4, of course). I'm thinking about it, anyway. It might only be a 32-bit mux for data and an 8-bit mux for address to the LUT. We really should boost that thing to 512 longs, though, to do this. Okay, nobody go ape-snarf.
    Fantastic news Chip.

    I really didn't think it would be much work as I have it working on the P1V, but just using AUGDS to get the standard jmpret to extended cog ram working.
    And yes, 512 longs make sense provided there is die space at the end of the work. Means we have double instruction space (with a few caveats) at full cog speed. And we can load overlays in there ultra-fast with the setq2/rdlong sequence.

    Makes the LUT extremely useful for a number of purposes.
  • jmgjmg Posts: 15,173
    Cluso99 wrote: »
    ...
    And yes, 512 longs make sense provided there is die space at the end of the work. Means we have double instruction space (with a few caveats) at full cog speed. And we can load overlays in there ultra-fast with the setq2/rdlong sequence.

    Makes the LUT extremely useful for a number of purposes.

    Sounding much like IDATA space in an 80C51
    - Extra RAM that comes almost for free, & has some caveats on usage, but is faster than full address length memory.
    Good for Stacks, & Data, & in P2 case, LUT and Code...


  • cgracey wrote: »
    Ken said that seven of you have bought the -A7 boards. Can you report on this thread how they're working out, so far?
    Chip,
    Only two minor issues with my Prop123-A7 board.
    1. One of the 3V3 user i/o pins is defective.
    2. All 4 of the RGB leds are defective. 2 don't work at all, 1 has no green and the remaining led green fails after it warms up.
    Haven't fully tested DAC's yet but all other I/O tests Ok.
    Overall a very nice board! :)



  • Oz, the WS2812B is easy to replace with a solder pencil since the pads on the bottom are near the corners. If you get in fast with a pencil you can tack it down on all 4 corners. These parts need to be baked really well for reflow else they come apart inside. Hand soldering unbaked parts is no problem if you are in and out with the pencil. If you have one color that is failing, that usually means popcorn internally.
  • I have several boards including the DE2-115 but I see that Arrow have the Bemicro CV A9 board quite cheap. Is this the right board to use for a full blown P2 minus the DACs?
  • Peter,
    AFAIK it has the same A9 device as the new Prop123-A9 board.
  • So if this is one that Chip will support then maybe we could do a group buy locally?
  • So if this is one that Chip will support then maybe we could do a group buy locally?
    Already got one Pete!

  • Chip
    The problem with the dead pin on my Prop123-A7 board turns out to be a error in the .qsf file.
    set_location_assignment PIN_P22 -to p[9]
    should be
    set_location_assignment PIN_T8 -to p[9]
    
    :);)
  • jmg wrote: »
    How many -A9 are being built ?

    We'll build 15 to 30 -A9s. We're waiting for the last part to arrive today or tomorrow, and then we'll have these come off the SMT line quickly. How quickly they are available will depend on two things: (a) expectations regarding documentation and our resource availability to produce it; and (b) Chip testing out the production run.

    I'd like your feedback on your expectations about documentation. What do you think the minimum needs would be?

    Ken Gracey
  • Heater.Heater. Posts: 21,230
    OK, wow, the bemicrocva9 is perhaps cheap enough that 'er in doors might approve the purchase.
    https://parts.arrow.com/item/detail/arrow-development-tools/bemicrocva9#nE2p

    Maybe i can keep up with you guys when the PII image is available.


  • cgraceycgracey Posts: 14,152
    edited 2015-09-09 15:32
    ozpropdev wrote: »
    Chip
    The problem with the dead pin on my Prop123-A7 board turns out to be a error in the .qsf file.
    set_location_assignment PIN_P22 -to p[9]
    should be
    set_location_assignment PIN_T8 -to p[9]
    
    :);)

    Oh, yes. I remember how we use that pin for DEV_CLRN now and we used another for p[9]. This changed on board rev's.

    We need to formalize our test procedure for that board. I wonder why all those RGB LEDs were bad! They are a rather superfluous feature, anyhow.
  • Ken GraceyKen Gracey Posts: 7,392
    edited 2015-09-09 16:34
    cgracey wrote: »
    ozpropdev wrote: »
    I wonder why all those RGB LEDs were bad! They are a rather superfluous feature, anyhow.

    Chip, are you referring to the WS2812 LEDs on the -A7 board? Strangely, we had troubles with WS2812s on the new Flight Controller, too. I think it was a P&P/reflow process issue that Kyle, Michael and Terell seem to have resolved.

    Ken Gracey
  • rjo__rjo__ Posts: 2,114
    Hi Chip,

    I have two P123 boards... I have not tested for problems that Ozpropdev reported. When first turned on, PX.exe works fine on both.
    But after the file is loaded, a rather longish wait is required before the P1V... from Jac... responds. During this period, serial loopback fails as well. Ozpropdev pointed toward the switch/multiplexer. This only happens at startup, with a cold board.
  • ozpropdev wrote: »
    Chip
    The problem with the dead pin on my Prop123-A7 board turns out to be a error in the .qsf file.
    set_location_assignment PIN_P22 -to p[9]
    should be
    set_location_assignment PIN_T8 -to p[9]
    
    :);)

    I fixed this in my P1V Github repo too. Thanks ozpropdev!
    https://github.com/jacgoudsmit/P1V/commit/59bac301ee3208acae77ac131bdc3ada618ed06a

    ===Jac
Sign In or Register to comment.