Any chance you'd be willing to post the hub exec instruction set?
I will do that later tonight.
To answer some questions, this FIFO is variable length and can grow to a depth of 20. It's job is just to smooth the herky-jerky relationship between the hub reads and hubexec/video.
We just got back from a father/son campout and I had a realization when I woke up for good at 3:45am about how to proceed with the video/hubexec buffering: A 20-stage FIFO in the cog that spits out hub longs at any rate at or below Fsys would simplify video quite a bit and provide hubexec instructions. And it would only take 640 flipflops.
I realized a FIFO can be built with each stage mux'ing either the hub read or the above FIFO stage into its inputs. Then we have a 5-bit counter to keep track of how many longs are stacked up, and what stage gets the next write. This would even bust out of the 16-long block constraint, since you can't really get started until you have your initial data, anyway. With this, you can get started with video or hub exec as soon as you get the first long, because the second and third are definitely following right behind. And if there's a stall in long consumption, there will be enough longs stacked up in the FIFO to allow loading to resume at the next identical hub opportunity (16 clocks later). This is a fix-all for hub long data needed at any rate, up to and including Fsys.
Thanks Chip, sorry if I get impatient, this looks as if the P16X64A can be wrapped up now I guess? Looking forward to that FPGA then
So how are you feeling? Maybe you need Som-Tum or a Basil Chicken Pizza ....
Those sound good!
I was meaning to post the current instruction set tonight, but as I got to work on my PC, it announced that it would be shutting down to install updates. There was no apparent way to tell it to hold off for a few hours. Roy got it working on the internet and now it has a lot of catching up to do, I guess. It says it's now installing update 39 of 71. It started out at 39 about 25 minutes ago and hasn't budged, yet. It might be offline for longer than I can stay up. This PC update stuff is obnoxious. It seems like it's been cutting into my work time a lot recently.
Before my computer started doing updates tonight, I had coded the 20-level FIFO in Verilog. I will post the code, for whatever it's worth, when I get my computer back.
For the video pixel timer, I'm switching to an NCO overflow, instead of a divide-by-N. The NCO begins at $00000000 with each pixel stream command, so you won't have roll-overs occurring at different places on a scan line, causing visible jitter. If you want divide-by-3, for example, use the value $55555556. It will cause a carry-out/new pixel on every third clock for as many pixels as you dare send out. For function generation, rather than use the overflow to step the pattern, the top 8-bits of the NCO will be used to index the 256-long LUT.
I had coded the 20-level FIFO in Verilog.
I will post the code, for whatever it's worth, when I get my computer back.
Good, That will be interesting.
FWIW the testcases I looked at needed 16 deep, and I used a flag for 'Valid-Tag' in the Tracking Memory-FIFO & a ReadCtr, for 532 registers.That should also code as Dual Port Ram, which can be smaller than registers & is faster in FPGA.
Relative to Nibble-Adder, a Tracking Memory 'FIFO' pluses are
* it allows linear memory playback,
* manages Odd-N and Even-N the same in fSys/N
* Gives easy granular launch/start, which can be after Memory is loaded.
If the TM_FIFO does not need the slot for the Video DMA, (and not need the COG RAM for LUT) it can give the SLOT to a more slothful COG during video bursts.
Minuses are it gives no support for fast copies into HUB memory ? (at least not the way I coded it ) & it needs more silicon.
Chip, turn auto update off, and then manually check for updates once you have finished working for the night.
Failing that, have a second laptop for internet, and remove your work PC from the net, that way it'll never need an inappropriate update, and be totally secure.
Unfortunately, it is not just windows anymore that does updates and other time consuming jobs. And they always happen at the worst time!
And it seems you can no longer prevent these programs from going online, if you need to be online for anything else.
For the video pixel timer, I'm switching to an NCO overflow, instead of a divide-by-N. The NCO begins at $00000000 with each pixel stream command, so you won't have roll-overs occurring at different places on a scan line, causing visible jitter. If you want divide-by-3, for example, use the value $55555556. It will cause a carry-out/new pixel on every third clock for as many pixels as you dare send out. For function generation, rather than use the overflow to step the pattern, the top 8-bits of the NCO will be used to index the 256-long LUT.
That sounds brilliant, Chip.
At the other end of the Fifo, can we write to OUTA or OUTB (for LCD), as well as DACs (for everything else?)
Unfortunately, it is not just windows anymore that does updates and other time consuming jobs.
Kubuntu only notifies of available updates, and even that is optional. Downloading and installing the updates is at my choosing. Just the way I like it.
That goes for every package that is maintained as a PPA. Hand installed packages or source compiled I have to seek the updates myself.
I had a friend just today comment on how snappy my system is. Naturally he's not a Linux user but is showing some interest of late. Funny thing is I've not really done anything particularly special to make it that way but I guess I do tend to tune all my desktops to be minimalistic no matter what the OS is. For example, first thing I do when using a Windoze box is choose classic look, aka Win2000. That usually immediately helps. And virus scanners are the second thing to be deinstalled after the Internet Explorer / Outlook tag team.
HDMI: minimum bit rate for the 8bit data * 3 RGB channels encoded as 10bits is 251.75mhz, would be great if P2 could handle a 15.734 crystal *16pll
Use three+one pins and a simple external lvds, or use 6+2 prop pins with differential drive.
Licensing fee, use the royalty free display-port and include a displayport-to-hdmi cable, though the hdmi-syndicate don't allow these cables they seem to be available again.
>Why would you want to use HDMI on a chip that only has a TOTAL memory of 512k?
You don't have to use the 24bit color debt, use 4bit*3 (4096 colors) and it also makes the 8/10b encoding lookup-table much smaller.
In 2-4years it will probably hard to find a monitor that have anything more than just hdmi/displayport digital inputs.
> An external chip can do analog conversion, and or one can get an analog conversion box for the monitor.
I'm not spending $6-$30 for an external chip/box when a few extra flip/flops or tuned to 250mhz P2 could give it to me for free.
I would be upset if it turns out that P2 is just 95% of reaching 480P hdmi.
I was meaning to post the current instruction set tonight, but as I got to work on my PC, it announced that it would be shutting down to install updates. There was no apparent way to tell it to hold off for a few hours. Roy got it working on the internet and now it has a lot of catching up to do, I guess. It says it's now installing update 39 of 71. It started out at 39 about 25 minutes ago and hasn't budged, yet. It might be offline for longer than I can stay up. This PC update stuff is obnoxious. It seems like it's been cutting into my work time a lot recently.
Before my computer started doing updates tonight, I had coded the 20-level FIFO in Verilog. I will post the code, for whatever it's worth, when I get my computer back.
While windows updates are still annoying, getting a SSD for your system disk gets the pain over with about 10x faster. LOTS of file IO and disk thrashing applying a windows patch. If you're willing to wait for a deal, it's pretty easy to find big SSD's below $0.50/GB now.
If there's space the "FIFO" sounds like a useful addition. I assume the "FIFO" can stream to OUTA/B and run it in reverse? (i.e. INA/B to hub)
With RDBLOC loading code overlays so fast, I do wonder if LMM will end up faster than HubExec? I'm assuming that the LMM compiler can add hints to LMM code so that the LMM interpreter can pre-load large loops into the cog memory? Something to test with the FPGA image anyway.
TV's however, will continue to have the analog in for a long time.
I keep reading this. I can't imagine why anyone would think it is true. What are all these analog sources people are using? I don't see any around me. Why would manufacturers keep providing for it? Things can change very quickly. Seems like only yesterday that tellies had tubes!
It seems to me that someone eventually will realize that all the TV composite stuff should disappear just because of extra cost and the institutional imperative to make better profit in public companies.
Some clever(?) marketeer will even tout it as a great feature because RF will no longer interfere or something. And therefore manufacturers will charge more for it ;-)
There are tiers too. Demographics. Demographics are constants for the most part too. There are women, men, kids, wealthy, not wealthy, educated, etc... Over very long time windows, those shift in terms of influence and share, of course. But they always exist.
Given that:
Early adopters will, of course, shun the older tech. The majority will be combining tech, new, old, whatever. Then there are the laggards, who use everything, until they can't.
TV manufacturers sell to everybody, so it's the laggards that determine a lot of features. The smarter TV vendors incorporate many features, balancing quality and capability. Some high end vendors may well focus on the upper crust, but they also look for margins on design, and other things too.
Because of this, many chip sets incorporate lots of features to keep it all rolling. Probably just providing the connectors and board area to support them, along with UI support are the big costs. We know how to do component / composite very well, and the chips IP blocks are baked in. Almost free now.
I expect some of this to go the way it has in laptop computers. TV manufacturers may well soon add a bus so that an expansion can provide those things for people over the very longer term. This will take the size and weight out of displays.
Monitors are increasingly specialized to be used with computers, which can be fitted with adapters and the use profile is different enough for it to all make sense, which explains the sharp move away from anything but digital, and the occasional legacy input.
In the US, the one input I've seen start to go away is S-video. It's niche enough that it never saw seriously broad adoption. And frankly, improvements in DSP technology has very seriously improved what we can get from composite. In my experiments with both the P1 and the P2 FPGA, I'm quite frankly stunned at what my plasma HDTV can eek out of a composite signal!
What you have to look at is the laggards and late majority. S-video really never established with either of those, and the moment it was eclipsed by component and digital formats, it really lost value. And it never established in some parts of the world at all! Component is this way to a degree as well, but it's got some advantages worth keeping it around.
I had an old tube TV, until I moved last time. Tubes are cool. Was fun to run it, but not worth hauling around.
The one tube I do enjoy still is the CRT. Only two left in the house! One is a VGA, the other is an ordinary definition TV, and it's HUGE! I'm ready to chuck the big CRT TV. I'll keep the VGA CRT around, until it breaks. Until this last round of HDTV devices, ordinary definition content was best viewed on the CRT. When my last plasma crapped out, I snagged a new one, which appears to render standard definition very well. I don't miss the CRT.
Video game consoles, home computers, VHS camcorders and players (there is a fairly large low end market surrounding these), DVD players, Digital broadcast receivers (DTV converters), composite camera "display" outputs found on older digital cameras, phone video outputs (newer phones output HDMI), are the most common I see.
Adding FIFO output support would of course require complementary FIFO input support. ;-)
Deeply engulfed in featurism again.
I think this is worth looking into, after we get a baseline FPGA image out.
At that time, it would also be worth looking at whether an external clock for the fifo, could be beneficial. The fifo could likely be clocked faster than the rest of the design. There may be benefits in being able to squirt up to 20 samples (a full fifo's worth) at higher than Fsys
I think this is worth looking into, after we get a baseline FPGA image out.
I think there you refer to 'reverse direction fifo ' suggested a couple of times above.
Would be interesting, as you say, maybe for a revision pass once the path one way is understood and proven.
At that time, it would also be worth looking at whether an external clock for the fifo, could be beneficial. The fifo could likely be clocked faster than the rest of the design. There may be benefits in being able to squirt up to 20 samples (a full fifo's worth) at higher than Fsys
Always nice (as is faster clocks on counters) - but I think not practical on any Synthesis design - not for something as complex as a FIFO, which would actually be Dual Port Sync Memory.
What could be practical is a tiny-prescaler type counter in the smart pins.
Whatever is needed to get SiliconMHz to 200MHz, but the headroom here is not really that much.
400MHz ? - maybe ? 800MHz ? hmm, still has to get past the pin-esd and buffer.
Apparently HDMI don't use IBM 8/10b encoding but a xor/xnor+inv 8-to-10 bit encoding
Could the video/smartpin-serializer do at least step1?
Step1: CHEAT always xor and never invert 8bit=8bit+%00
Step2: implement xnor when it results in fever transition or/and invert option to keep DC balance.
It would also be easy to create a 4 bit lookup table that already have xor'ed the bits and expanded it to 10bit = 4096 colors as RGB can use same table.
For P2, with built in fast DACs, it'd be pretty hard to think of a good reason to do HDMI with external chip instead of VGA... Still, HDMI gives a perfect digital signal and can also include digital 5.1 audio. Also, I think HDMI can go longer distances...
But, I don't think I'd want to give up ~30 pins for video when 4 pins can give you pretty much the same picture...
Comments
I will do that later tonight.
To answer some questions, this FIFO is variable length and can grow to a depth of 20. It's job is just to smooth the herky-jerky relationship between the hub reads and hubexec/video.
Great! Hope you had a good time.
So how are you feeling? Maybe you need Som-Tum or a Basil Chicken Pizza ....
Thanks Chip, sorry if I get impatient, this looks as if the P16X64A can be wrapped up now I guess? Looking forward to that FPGA then
Those sound good!
I was meaning to post the current instruction set tonight, but as I got to work on my PC, it announced that it would be shutting down to install updates. There was no apparent way to tell it to hold off for a few hours. Roy got it working on the internet and now it has a lot of catching up to do, I guess. It says it's now installing update 39 of 71. It started out at 39 about 25 minutes ago and hasn't budged, yet. It might be offline for longer than I can stay up. This PC update stuff is obnoxious. It seems like it's been cutting into my work time a lot recently.
Before my computer started doing updates tonight, I had coded the 20-level FIFO in Verilog. I will post the code, for whatever it's worth, when I get my computer back.
It's the video that needs the deep FIFO.
For the video pixel timer, I'm switching to an NCO overflow, instead of a divide-by-N. The NCO begins at $00000000 with each pixel stream command, so you won't have roll-overs occurring at different places on a scan line, causing visible jitter. If you want divide-by-3, for example, use the value $55555556. It will cause a carry-out/new pixel on every third clock for as many pixels as you dare send out. For function generation, rather than use the overflow to step the pattern, the top 8-bits of the NCO will be used to index the 256-long LUT.
Windows can be royal pain, makes a good case for a 1 TB USB3 drive, and more than one PC ..
Good, That will be interesting.
FWIW the testcases I looked at needed 16 deep, and I used a flag for 'Valid-Tag' in the Tracking Memory-FIFO & a ReadCtr, for 532 registers.That should also code as Dual Port Ram, which can be smaller than registers & is faster in FPGA.
Relative to Nibble-Adder, a Tracking Memory 'FIFO' pluses are
* it allows linear memory playback,
* manages Odd-N and Even-N the same in fSys/N
* Gives easy granular launch/start, which can be after Memory is loaded.
If the TM_FIFO does not need the slot for the Video DMA, (and not need the COG RAM for LUT) it can give the SLOT to a more slothful COG during video bursts.
Minuses are it gives no support for fast copies into HUB memory ? (at least not the way I coded it ) & it needs more silicon.
Is that LUT still in 'borrowed' COG RAM, or separate ?
Failing that, have a second laptop for internet, and remove your work PC from the net, that way it'll never need an inappropriate update, and be totally secure.
And it seems you can no longer prevent these programs from going online, if you need to be online for anything else.
That sounds brilliant, Chip.
At the other end of the Fifo, can we write to OUTA or OUTB (for LCD), as well as DACs (for everything else?)
Kubuntu only notifies of available updates, and even that is optional. Downloading and installing the updates is at my choosing. Just the way I like it.
That goes for every package that is maintained as a PPA. Hand installed packages or source compiled I have to seek the updates myself.
I had a friend just today comment on how snappy my system is. Naturally he's not a Linux user but is showing some interest of late. Funny thing is I've not really done anything particularly special to make it that way but I guess I do tend to tune all my desktops to be minimalistic no matter what the OS is. For example, first thing I do when using a Windoze box is choose classic look, aka Win2000. That usually immediately helps. And virus scanners are the second thing to be deinstalled after the Internet Explorer / Outlook tag team.
Use three+one pins and a simple external lvds, or use 6+2 prop pins with differential drive.
Licensing fee, use the royalty free display-port and include a displayport-to-hdmi cable, though the hdmi-syndicate don't allow these cables they seem to be available again.
I love the new hub bandwidth, and the FIFO is very promising.
Any chance of multiplying the system clock before feeding it to the NCO?
1080p needs a 165MHz dot clock...
If possible, have the fifo support parallel output (8/16/24/32) for LCD applications, and off-chip DVI phy.
Adding FIFO output support would of course require complementary FIFO input support. ;-)
Deeply engulfed in featurism again.
You don't have to use the 24bit color debt, use 4bit*3 (4096 colors) and it also makes the 8/10b encoding lookup-table much smaller.
In 2-4years it will probably hard to find a monitor that have anything more than just hdmi/displayport digital inputs.
An external chip can do analog conversion, and or one can get an analog conversion box for the monitor.
I'm not spending $6-$30 for an external chip/box when a few extra flip/flops or tuned to 250mhz P2 could give it to me for free.
I would be upset if it turns out that P2 is just 95% of reaching 480P hdmi.
No crazier than doing 1600x1200 on the P1
While windows updates are still annoying, getting a SSD for your system disk gets the pain over with about 10x faster. LOTS of file IO and disk thrashing applying a windows patch. If you're willing to wait for a deal, it's pretty easy to find big SSD's below $0.50/GB now.
If there's space the "FIFO" sounds like a useful addition. I assume the "FIFO" can stream to OUTA/B and run it in reverse? (i.e. INA/B to hub)
With RDBLOC loading code overlays so fast, I do wonder if LMM will end up faster than HubExec? I'm assuming that the LMM compiler can add hints to LMM code so that the LMM interpreter can pre-load large loops into the cog memory? Something to test with the FPGA image anyway.
I keep reading this. I can't imagine why anyone would think it is true. What are all these analog sources people are using? I don't see any around me. Why would manufacturers keep providing for it? Things can change very quickly. Seems like only yesterday that tellies had tubes!
I have a tubie telly ;-)
It seems to me that someone eventually will realize that all the TV composite stuff should disappear just because of extra cost and the institutional imperative to make better profit in public companies.
Some clever(?) marketeer will even tout it as a great feature because RF will no longer interfere or something. And therefore manufacturers will charge more for it ;-)
There are tiers too. Demographics. Demographics are constants for the most part too. There are women, men, kids, wealthy, not wealthy, educated, etc... Over very long time windows, those shift in terms of influence and share, of course. But they always exist.
Given that:
Early adopters will, of course, shun the older tech. The majority will be combining tech, new, old, whatever. Then there are the laggards, who use everything, until they can't.
TV manufacturers sell to everybody, so it's the laggards that determine a lot of features. The smarter TV vendors incorporate many features, balancing quality and capability. Some high end vendors may well focus on the upper crust, but they also look for margins on design, and other things too.
Because of this, many chip sets incorporate lots of features to keep it all rolling. Probably just providing the connectors and board area to support them, along with UI support are the big costs. We know how to do component / composite very well, and the chips IP blocks are baked in. Almost free now.
I expect some of this to go the way it has in laptop computers. TV manufacturers may well soon add a bus so that an expansion can provide those things for people over the very longer term. This will take the size and weight out of displays.
Monitors are increasingly specialized to be used with computers, which can be fitted with adapters and the use profile is different enough for it to all make sense, which explains the sharp move away from anything but digital, and the occasional legacy input.
In the US, the one input I've seen start to go away is S-video. It's niche enough that it never saw seriously broad adoption. And frankly, improvements in DSP technology has very seriously improved what we can get from composite. In my experiments with both the P1 and the P2 FPGA, I'm quite frankly stunned at what my plasma HDTV can eek out of a composite signal!
What you have to look at is the laggards and late majority. S-video really never established with either of those, and the moment it was eclipsed by component and digital formats, it really lost value. And it never established in some parts of the world at all! Component is this way to a degree as well, but it's got some advantages worth keeping it around.
I had an old tube TV, until I moved last time. Tubes are cool. Was fun to run it, but not worth hauling around.
The one tube I do enjoy still is the CRT. Only two left in the house! One is a VGA, the other is an ordinary definition TV, and it's HUGE! I'm ready to chuck the big CRT TV. I'll keep the VGA CRT around, until it breaks. Until this last round of HDTV devices, ordinary definition content was best viewed on the CRT. When my last plasma crapped out, I snagged a new one, which appears to render standard definition very well. I don't miss the CRT.
Video game consoles, home computers, VHS camcorders and players (there is a fairly large low end market surrounding these), DVD players, Digital broadcast receivers (DTV converters), composite camera "display" outputs found on older digital cameras, phone video outputs (newer phones output HDMI), are the most common I see.
I think this is worth looking into, after we get a baseline FPGA image out.
At that time, it would also be worth looking at whether an external clock for the fifo, could be beneficial. The fifo could likely be clocked faster than the rest of the design. There may be benefits in being able to squirt up to 20 samples (a full fifo's worth) at higher than Fsys
See below.
I think there you refer to 'reverse direction fifo ' suggested a couple of times above.
Would be interesting, as you say, maybe for a revision pass once the path one way is understood and proven.
Always nice (as is faster clocks on counters) - but I think not practical on any Synthesis design - not for something as complex as a FIFO, which would actually be Dual Port Sync Memory.
What could be practical is a tiny-prescaler type counter in the smart pins.
Whatever is needed to get SiliconMHz to 200MHz, but the headroom here is not really that much.
400MHz ? - maybe ? 800MHz ? hmm, still has to get past the pin-esd and buffer.
Could the video/smartpin-serializer do at least step1?
Step1: CHEAT always xor and never invert 8bit=8bit+%00
Step2: implement xnor when it results in fever transition or/and invert option to keep DC balance.
It would also be easy to create a 4 bit lookup table that already have xor'ed the bits and expanded it to 10bit = 4096 colors as RGB can use same table.
But, I don't think I'd want to give up ~30 pins for video when 4 pins can give you pretty much the same picture...