Chip, I misunderstood the whole thing... I thought you were simply trying to do HDMI in SW with the existing features, using the LUT ram for 8B/10B and the smartpins as serializers... *NOT* adding more stuff to the FPGA
"Star Trek: The Wrath of Ken" in 3, 2, 1...
Ken knows and he's happy about it. Otherwise, I wouldn't have told him.
I wonder if there are other things in the P2, Ken (and we) do not know about yet.
I am absolute happy about the clock speed for example. Discussed was 180 hey maybe 192 to fit USB better. The hope was 200 maybe?
Now Chip is running 250 easy with not even having a lot of caps, just bench supplies. And Peter runs 340 stable, even 360 with some cooling.
Yes, and those are real system speeds. We can do meaningful stuff both on the development and application side of things.
I can totally see a range of clocks here. The really high clock, water cool, whatever P2, development system... and then a range of Target systems, low clock low-power, you know the drill.
Is the official supported clock speed of the P2 now going to be 250mhz?
There are voltage and temperature limits at which we can guarantee that performance. We just need ON Semi to run some analyses and tell us what they are.
Guess I‘m a bit slow, sorry. Are we talking about bringing HDMI to the current P2 (as kind of a logic update for the B-silicon). Or is this feature adressed to the FPGA or „P2++“.
Probably trying to use current P2 A-reversion and by just using software,
and if it turns out that it's just one thing missing in hardware to do it, I guess it will then come to a decision for B-reversion?
Guess I‘m a bit slow, sorry. Are we talking about bringing HDMI to the current P2 (as kind of a logic update for the B-silicon). Or is this feature adressed to the FPGA or „P2++“.
All of the above
It is already in the FPGA/Verilog and is being tested, by Chip. The rev B is the P2++.
Probably trying to use current P2 A-reversion and by just using software,
and if it turns out that it's just one thing missing in hardware to do it, I guess it will then come to a decision for B-reversion?
That "one thing" got added to the streamer and will go into the respin. Yes, it's going to be software driven video, just like the analog video is. But, the stream mechanics will get handled like they are for analog. All that allows for a software kernel, intended to fetch, or generate, display data, from RAM, or on the fly, like text, or tiles.
And, being software, the target is a basic "baseband" like stream, 640x480, video only. However, that's not set in stone. Over time, software video systems tend to get exploited to deliver much greater overall capability and fidelity than the original, conservative design targets specify.
Racing the beam HDMI style. I'm looking forward to it. At a minimum, people can get a bitmap with very little code. Similar to the existing bitmap test / demo code out there now.
HDMI is being added. I will post the Verilog code that constitutes the whole change when it's done. It's not much, just an HDMI-mode bit, the encoder, and a mux to swap {24'b0, hdmi[7:0]} in where normaldata[31:0] usually goes.
David, that is my understanding too. These very early test chips should be identical to the ones packaged in the intended end-use package and will go onto the Parallax boards many of us will get started on.
Right now, Parallax got something like 14? 12? Rush job, "let's see whether it works" that went out to the people most focused on P2 testing.
Rayman,
Pretty sure they will still get the ~1500 first run chips and put some/all on boards for us to buy/get. Primarily for wider testing and tools development, but also for people to start working on project for the P2.
I believe Chip/Ken will wait for more testing to occur before they pull the trigger on the respin.
This minor change to add HDMI ability for the respin is likely worth it in Ken's eyes, because it's really low risk for a fairly big payoff.
It's worth it in mine too. Didn't cost much logic, it's a very hot feature, and it's in a body of code that appears to have worked without a hitch. Known ground, so to speak.
I think the big driver on that is the clock speed matchup. All along, during some of those discussions, the opinion was "HDMI = too fast." Nice to learn that is not the case.
A full test, given we've got basically one round of chips to test on makes all sorts of sense. It's gonna vet all those, "we should have", or "if only we had" cases, along with real errors and fails, like that signed thing.
Without any exceptional agreement by ON Semi, they are going to send us 175 Amkor-packaged chips on November 8. There are more chips which could be packaged from the first wafer run, but they don't want to ship too much before the product qualification is complete. These 175 should be enough to get everyone started. This came up in a discussion last week. Yes, there are enough to make 1500 chips, but their business model is not in agreement with turning those into a production run. If we wind up needing more chips, I think they'll help us out, but for now, we've only got 175 of them coming.
Hmm, I guess 7:1 TDMS for embedded LCD's, as an option, is not on the cards. It would up the logic again to have any config.
It wouldn't be as effective anyway, since there is no scan converter when connecting directly to the LCD panel, it would be limited LCD choice of 640x480 only. Better to output the flat pixel data and use a LVDS driver chip.
Chip,
Ok, so only 175 of the "rev A" ones, that's probably enough for testing and tool dev over the next few months. Probably best to not get too many of this version out in the wild, since we'll have the final version early next year.
Comments
I thought so too. Had it been otherwise, we would have found "something odd" during respin testing.
I am absolute happy about the clock speed for example. Discussed was 180 hey maybe 192 to fit USB better. The hope was 200 maybe?
Now Chip is running 250 easy with not even having a lot of caps, just bench supplies. And Peter runs 340 stable, even 360 with some cooling.
Fun,
Mike
I can totally see a range of clocks here. The really high clock, water cool, whatever P2, development system... and then a range of Target systems, low clock low-power, you know the drill.
There are voltage and temperature limits at which we can guarantee that performance. We just need ON Semi to run some analyses and tell us what they are.
and if it turns out that it's just one thing missing in hardware to do it, I guess it will then come to a decision for B-reversion?
All of the above
It is already in the FPGA/Verilog and is being tested, by Chip. The rev B is the P2++.
That "one thing" got added to the streamer and will go into the respin. Yes, it's going to be software driven video, just like the analog video is. But, the stream mechanics will get handled like they are for analog. All that allows for a software kernel, intended to fetch, or generate, display data, from RAM, or on the fly, like text, or tiles.
And, being software, the target is a basic "baseband" like stream, 640x480, video only. However, that's not set in stone. Over time, software video systems tend to get exploited to deliver much greater overall capability and fidelity than the original, conservative design targets specify.
Racing the beam HDMI style. I'm looking forward to it. At a minimum, people can get a bitmap with very little code. Similar to the existing bitmap test / demo code out there now.
really?
Mike
Are we cancelling Chipmas?
Right now, Parallax got something like 14? 12? Rush job, "let's see whether it works" that went out to the people most focused on P2 testing.
Pretty sure they will still get the ~1500 first run chips and put some/all on boards for us to buy/get. Primarily for wider testing and tools development, but also for people to start working on project for the P2.
I believe Chip/Ken will wait for more testing to occur before they pull the trigger on the respin.
This minor change to add HDMI ability for the respin is likely worth it in Ken's eyes, because it's really low risk for a fairly big payoff.
I think the big driver on that is the clock speed matchup. All along, during some of those discussions, the opinion was "HDMI = too fast." Nice to learn that is not the case.
A full test, given we've got basically one round of chips to test on makes all sorts of sense. It's gonna vet all those, "we should have", or "if only we had" cases, along with real errors and fails, like that signed thing.
It wouldn't be as effective anyway, since there is no scan converter when connecting directly to the LCD panel, it would be limited LCD choice of 640x480 only. Better to output the flat pixel data and use a LVDS driver chip.
Might work out nicely...
I have been waiting for Chipmas for such a long time.
Ok, so only 175 of the "rev A" ones, that's probably enough for testing and tool dev over the next few months. Probably best to not get too many of this version out in the wild, since we'll have the final version early next year.
But I will be happy if it really is Chipmas!
Could this mode: rrrrrrrrrr_gggggggggg_bbbbbbbbbb_x1 = raw 10b encoding
be used for fast P2-P2 communications?
Maybe have one lane be %1010101... for a DDR clock?