Shop OBEX P1 Docs P2 Docs Learn Events
New Hub Scheme For Next Chip - Page 13 — Parallax Forums

New Hub Scheme For Next Chip

1101113151637

Comments

  • SeairthSeairth Posts: 2,474
    edited 2014-05-15 18:44
    cgracey wrote: »
    ... VID32........32-bit hub-to-DAC mode at Fsys/N ...

    What is "N" in the "Fsys/N"?
  • jmgjmg Posts: 15,140
    edited 2014-05-15 18:44
    cgracey wrote: »
    ... Now, there can be different instructions to do different video output streams. There's no longer a need to chain video commands, in other words. This means that we CAN have a 256 LUT by reading the pixel from hub, translating them via cog RAM into 32-bit patterns, and outputting them to the DACs. This simplifies video quite a bit.

    There can now be all kinds of video output instructions that get the job done in a simple way:

    VID32........32-bit hub-to-DAC mode at Fsys/N
    VID16........16-bit hub-to-DAC mode at Fsys/N
    VID8..........8-bit hub-to-LUT-to-DAC mode at Fsys/N
    VID4..........4-bit hub-to-LUT-to-DAC mode at Fsys/N
    VID2..........2-bit hub-to-LUT-to-DAC mode at Fsys/N
    VID1..........1-bit hub-to-LUT-to-DAC mode at Fsys/N

    Once these instructions are over, they can return the DAC states to whatever they were before, with a mapped DAC register holding the four 8-bit values. That way, horizontal sync's can be done with 'MOV DAC,dacstates' and 'WAIT clocks' instructions. This simplifies the video greatly. Because there is no decoupling, though, the cog will be busy while it generates the pixels.

    Sounding very good :) ( wait - Did you mean fSys/N or fSys ? )
    I guess these can also map to Pins (skip the DAC ?)

    To clarify, these are DMA like opcodes that are 'launched' somehow and stream from HUB until a count, or stopped ?
    ( I would call the LUT ones VIDLUT8, VIDLUT4 etc )

    Can you give a code snippet for a Video line ?

    Re the LUT ones to Read from HUB and lookup via GOG RAM - I guess there is a LUT pipeline so the first Video Pixel is one-clock delayed from the HubRead, and that read will be Nibble-LSB-Sync'd ?

    If scan lines are not 16N, keeping time-sync across lines might get tricky ?

    If using WAIT, the COG itself will be low power, but the DMA will be spinning, so Power will be DAC's + in-between COG power.

    Q; Is there a WRLONG, REG, PTR-- opcode paired with WRLONG, REG, PTR++, or is it only PTR++ in this latest COG design ?
  • cgraceycgracey Posts: 14,131
    edited 2014-05-15 18:50
    Seairth wrote: »
    What is "N" in the "Fsys/N"?


    1, 2, 3,... 64

    Fsys is the system clock frequency (200MHz).

    So, at 200MHz, you could output pixels at 200MHz, 100Mhz, 66MHz, 50MHz, 40MHz, etc. Those seem a little choppy, but if you need another frequency, you could use a different crystal or change the master clock multiplier.
  • potatoheadpotatohead Posts: 10,253
    edited 2014-05-15 18:51
    Oh man! I was on a similar path, when you mentioned the xfer types above.

    It's OK that the COG is busy, because any number of other ones can be writing scan lines / tiles / whatever to the HUB. That's actually quite nice.

    This also means we can do color managment of a sorts too. The COG will need to do some computations, but once they are done, they are done for the palette modes. :) I was struggling with how that might happen before.

    Preserving the whole scan line is a big win!

    Will writing out a part of a scan line still be an option? (Yes, I have reasons for this.)
  • cgraceycgracey Posts: 14,131
    edited 2014-05-15 18:57
    jmg wrote: »
    Sounding very good :) ( wait - Did you mean fSys/N or fSys ? )
    I guess these can also map to Pins (skip the DAC ?)

    To clarify, these are DMA like opcodes that are 'launched' somehow and stream from HUB until a count, or stopped ?
    ( I would call the LUT ones VIDLUT8, VIDLUT4 etc )

    Can you give a code snippet for a Video line ?

    Re the LUT ones to Read from HUB and lookup via GOG RAM - I guess there is a LUT pipeline so the first Video Pixel is one-clock delayed from the HubRead, and that read will be Nibble-LSB-Sync'd ?

    If scan lines are not 16N, keeping time-sync across lines might get tricky ?

    If using WAIT, the COG itself will be low power, but the DMA will be spinning, so Power will be DAC's + in-between COG power.

    Q; Is there a WRLONG, REG, PTR-- opcode paired with WRLONG, REG, PTR++, or is it only PTR++ in this latest COG design ?


    I mean Fsys divided by an integer (1..64).

    Because these instructions would stall execution for their duration, the cog RAM can be used as a LUT. Practically, you would do ONE instruction for a whole visible scan line, unless you didn't mind stalled-pixel zones between instructions. I need to work out the details yet on how this would be coded.

    The PTRA/PTRB expressions can be -- or ++, before or after. This video streaming would definitely be forward-only.
  • jmgjmg Posts: 15,140
    edited 2014-05-15 18:59
    cgracey wrote: »
    1, 2, 3,... 64

    Fsys is the system clock frequency (200MHz).

    So, at 200MHz, you could output pixels at 200MHz, 100Mhz, 66MHz, 50MHz, 40MHz, etc. Those seem a little choppy, but if you need another frequency, you could use a different crystal or change the master clock multiplier.
    Great - but how does it manage (eg) fSys/3, and still stay Rotator slot-sync'd ? or do you now have a Nibble Adder in there ?
  • cgraceycgracey Posts: 14,131
    edited 2014-05-15 19:00
    potatohead wrote: »
    Oh man! I was on a similar path, when you mentioned the xfer types above.

    It's OK that the COG is busy, because any number of other ones can be writing scan lines / tiles / whatever to the HUB. That's actually quite nice.

    This also means we can do color managment of a sorts too. The COG will need to do some computations, but once they are done, they are done for the palette modes. :) I was struggling with how that might happen before.

    Preserving the whole scan line is a big win!

    Will writing out a part of a scan line still be an option? (Yes, I have reasons for this.)


    What do you mean by writing out part of a scan line?

    The cog generating the video could reload its 'palette' in the vertical blank with a block-load instruction.
  • potatoheadpotatohead Posts: 10,253
    edited 2014-05-15 19:02
    I mean changing modes. Say you want 2 bits for x part of the line, then you want 8 bits for part, then go back to 2 bits...

    In the other video engine, and to some (tricky) degree on P1, it is easy to make a window that is different resolution / color depth from the rest of the screen.

    One use would be a character driver that has a few bitmap regions for high color, perhaps different resolution, etc... Done to maximize RAM and or present data in a real-time way.

    Yes, palette changes during VBLANK make perfect sense. HBLANK would be excellent, but no worries there. Might be possible, but not a focus IMHO.
  • jmgjmg Posts: 15,140
    edited 2014-05-15 19:04
    potatohead wrote: »
    Will writing out a part of a scan line still be an option? (Yes, I have reasons for this.)

    Do you mean mixing Text and Graphics ? - I would think so, with the 'DAC default pixel' proviso Chip mentioned already. - but you'd probably want a small tramline anyway
  • cgraceycgracey Posts: 14,131
    edited 2014-05-15 19:05
    jmg wrote: »
    Great - but how does it manage (eg) fSys/3, and still stay Rotator slot-sync'd ? or do you now have a Nibble Adder in there ?


    I'm not sure yet. It might need to buffer a block first in 16 cycles, then transfer that to the shifter and load the next block. That would take a lot of flops, though. I need to map out the timing.

    You said your nibble adder was good for odd-N values, right?
  • potatoheadpotatohead Posts: 10,253
    edited 2014-05-15 19:07
    jmg wrote: »
    Do you mean mixing Text and Graphics ? - I would think so, with the 'DAC default pixel' proviso Chip mentioned already. - but you'd probably want a small tramline anyway

    Yes that is one use. There are others. Since we are in software, display lists could be driving the display too.
  • jmgjmg Posts: 15,140
    edited 2014-05-15 19:07
    cgracey wrote: »
    You said your nibble adder was good for odd-N values, right?

    Yes, but I think I may have just solved the Even Values issue too :) - just compiling now...
  • cgraceycgracey Posts: 14,131
    edited 2014-05-15 19:08
    potatohead wrote: »
    I mean changing modes. Say you want 2 bits for x part of the line, then you want 8 bits for part, then go back to 2 bits...

    In the other video engine, and to some (tricky) degree on P1, it is easy to make a window that is different resolution / color depth from the rest of the screen.

    One use would be a character driver that has a few bitmap regions for high color, perhaps different resolution, etc... Done to maximize RAM and or present data in a real-time way.

    Yes, palette changes during VBLANK make perfect sense. HBLANK would be excellent, but no worries there. Might be possible, but not a focus IMHO.


    There would probably be time for a palette reload in hsync. It would take 256 clocks, or 1.28us. No problem.

    About switching modes: It could be done, but there would be some dead time between video commands, where the pixel value would stay static. That would be tolerable in many cases, I think.
  • potatoheadpotatohead Posts: 10,253
    edited 2014-05-15 19:11
    We get a slightly longer pixel somewhere. No worries. Really, I guess the question is we can specify X pixels at Fsys/y. At the speeds we are talking, that's a little tiny dead spot. Or, a border.

    1.28... Yeah. I forget the speed of things relative to the last FPGA :)
  • jmgjmg Posts: 15,140
    edited 2014-05-15 19:14
    potatohead wrote: »
    We get a slightly longer pixel somewhere. No worries. Really, I guess the question is we can specify X pixels at Fsys/y. At the speeds we are talking, that's a little tiny dead spot.

    I think Chip said that 'dead spots' can have a Default value (at least in the DAC cases) - maybe also in the direct-to-pins case ?
  • potatoheadpotatohead Posts: 10,253
    edited 2014-05-15 19:17
    Yeah, "dead spot" really isn't the right word. It's more like an overhang, or just extended pixel, etc...
  • TubularTubular Posts: 4,620
    edited 2014-05-15 19:18
    Chip know this isn't your current focus, but what registers are left in the high cog area? OUTA, OUTB, DIRA, DIRB, presumably. A DACS register? PTRA & B?

    Counter and indirect registers are gone, presumably.
  • Cluso99Cluso99 Posts: 18,066
    edited 2014-05-15 19:20
    Chip,
    May I interpose a suggestion here...

    Could we just get an FPGA with the new hub method out so we can begin some testing please?
    I don't much care what else it has, or is missing. At least we could do some testing.

    BTW I have my own reservations on the new hub scheme, and yet I love the BW it offers.
    Anyway, you have done the Verilog, so why waste it while everyone argues over it.
    Lets stop arguing and try it!

    So the same goes for video, DACs, etc. Please wait until you get us an FPGA image to play with... please, please, please.
  • cgraceycgracey Posts: 14,131
    edited 2014-05-15 19:22
    Tubular wrote: »
    Chip know this isn't your current focus, but what registers are left in the high cog area? OUTA, OUTB, DIRA, DIRB, presumably. A DACS register? PTRA & B?

    Counter and indirect registers are gone, presumably.

    You got it pretty straight.

    1F7 = DACS?
    1F8 = PTRA
    1F9 = PTRB
    1FA = INA
    1FB = INB
    1FC = OUTA
    1FD = OUTB
    1FE = DIRA
    1FF = DIRB
  • cgraceycgracey Posts: 14,131
    edited 2014-05-15 19:26
    Cluso99 wrote: »
    Chip,
    May I interpose a suggestion here...

    Could we just get an FPGA with the new hub method out so we can begin some testing please?
    I don't much care what else it has, or is missing. At least we could do some testing.

    BTW I have my own reservations on the new hub scheme, and yet I love the BW it offers.
    Anyway, you have done the Verilog, so why waste it while everyone argues over it.
    Lets stop arguing and try it!

    So the same goes for video, DACs, etc. Please wait until you get us an FPGA image to play with... please, please, please.


    It's not all tied together yet and I don't know when it will be, exactly. Stuff just needs to come together a little more before I can make an FPGA image. As soon as I have one, though, you will have one.
  • SeairthSeairth Posts: 2,474
    edited 2014-05-15 19:55
    cgracey wrote: »
    Here is the Verilog code that makes the memory system

    I've been trying to grok the timing of this, but I keep losing track. I think it's time to throw it into ModelSim. Do you happen to have a test script for this and would you be willing to share it?
  • SeairthSeairth Posts: 2,474
    edited 2014-05-15 19:58
    cgracey wrote: »
    1, 2, 3,... 64

    Fsys is the system clock frequency (200MHz).

    So, at 200MHz, you could output pixels at 200MHz, 100Mhz, 66MHz, 50MHz, 40MHz, etc. Those seem a little choppy, but if you need another frequency, you could use a different crystal or change the master clock multiplier.

    Where do the 1..64 come from? Is it an instruction parameter? Something to do with the DACs?
  • cgraceycgracey Posts: 14,131
    edited 2014-05-15 19:58
    Seairth wrote: »
    I've been trying to grok the timing of this, but I keep losing track. I think it's time to throw it into ModelSim. Do you happen to have a test script for this and would you be willing to share it?


    I don't have a test script. One thing that might throw you off is the ENA signal. That is an active-low chip-wide RESET signal. It's only low during whole-chip reset. After that, it stays high. Just imagine that the 's' flops are initialized to the reset pattern, and thereafter they rotate by four bits. You could get rid of the ENA sensitivity everywhere but on the 's' flops.
  • cgraceycgracey Posts: 14,131
    edited 2014-05-15 19:59
    Seairth wrote: »
    Where do the 1..64 come from? Is it an instruction parameter? Something to do with the DACs?

    It will be a parameter used by the video instructions to divide the clock by, in order to get the pixel clock. I think 4 bits will be adequate, actually, for 1..16 values.
  • TubularTubular Posts: 4,620
    edited 2014-05-15 20:20
    cgracey wrote: »
    It will be a parameter used by the video instructions to divide the clock by, in order to get the pixel clock. I think 4 bits will be adequate, actually, for 1..16 values.

    Is 'N' a global across the entire chip, or can each cog have a different 'N'?

    Ariba (here) mentioned a possible way to store the NTSC chroma as a sequence of precalculated samples output to the DACs. Ie a 'color' would be encoded by embedding the appropriate carrier into the DAC samples themselves, and outputting at the Fsys rate, but rotating through the sequence of dac samples.

    If you always keep a 256 element LUT, then in 16 color mode, you could afford a sequence of 16 samples, for instance
  • potatoheadpotatohead Posts: 10,253
    edited 2014-05-15 20:25
    It's gonna be per COG, as the COG will be doing video directly, with it's buffer in the HUB.
  • David BetzDavid Betz Posts: 14,511
    edited 2014-05-15 20:50
    cgracey wrote: »
    It's not all tied together yet and I don't know when it will be, exactly. Stuff just needs to come together a little more before I can make an FPGA image. As soon as I have one, though, you will have one.
    Any chance hub execution will appear in this new chip or has that idea been abandoned?
  • Cluso99Cluso99 Posts: 18,066
    edited 2014-05-15 21:08
    I am not sure how this video is going to work...

    It is going to get its video data directly from Hub
    Fantastic, but doesn't that mean that the cog will not be able to use hub while this is happening?
    BTW I am fine with this. I would even be happy to sacrifice the cog totally for this (we have 16 of them).
  • Cluso99Cluso99 Posts: 18,066
    edited 2014-05-15 21:19
    David Betz wrote: »
    Any chance hub execution will appear in this new chip or has that idea been abandoned?
    I think HUBEXEC may currently be in the too hard basket for the time being.

    But, when implemented, all we require to start trying it is this...
    1. PC counter to be expanded to 17 bits (long address)
    2. CALLH @/#nnnnnnnnnnnnnnnnn [WC,WZ] 'return address stored in a fixed location (say $1EF for now)
    3. RETH [WC,WZ] 'jmp indirectly via the fixed location (say $1EF for now)
    4. It would be nice to have a JMPH version of the CALLH (does not store the return address) but we could get by with the above for testing.
    5. When fetching instructions from Hub, no caching to be used - just wait for hub cycle and load the contents directly to the ALU. Again, all we need for testing.

    I am trying to keep this absolutely as simple as possible, so that Chip can implement this easily.
    Any advances (if any) can be done later. At least we can then begin testing.
  • cgraceycgracey Posts: 14,131
    edited 2014-05-15 21:20
    Tubular wrote: »
    If you always keep a 256 element LUT, then in 16 color mode, you could afford a sequence of 16 samples, for instance


    Good idea. 16x oversampling for NTSC would be ~57MHz. It would be easy to make a one-DAC byte output mode, as well, in the video shifter. There could even be a mode where the byte output is looked up from 4 longs, giving 16 discrete byte values, with wrapping inside the 4 longs. That way, pixels could be any duration. Actually, the initial pixels could be bytes, where 4 bits determine which 4-long group and the other 4 bits determine initial offset within those 16 bytes. Ah, maybe that's getting too complex.
Sign In or Register to comment.