I had a big scare overnight. I was looking through some OnSemi process document and I saw current-density guidelines for resistors being 100uA/um. I had designed for 500uA/um, based on some other document, which was way too hot. I contacted OnSemi and, thankfully, they said 500uA/um is actually fine for the RPPOLY resistor that I'm using in the 123.75-ohm fast DAC. I had already redesigned it and was planning on some protracted layout efforts. Fortunately, we don't need to fret about it. Whew!
I've been working all night, but I'll look into it when I get up.
Np big rush. Rest.
The problem is that the FPGA image doesn't output DAC0, which is Luma for S-Video. It shifts everything down by one, so that we get the three DAC output channels on DAC0, DAC1, and DAC2, while what should be DAC0 is digital P0, used for VGA V-sync. I'll need to make a special image, or, better yet, use some switch on the FPGA board. Are you still using the DE2-115, or do you have a Prop123-A9?
Ahh, that's the trouble right there! Good to know. What I got after, what I thought was a configuration based on HOT, accounting for the 8 bit DACS, was composite on both channels.
And here's the thing. If that circuit is really just lifted from the HOT chip, and the only real difference is the NCO, instead of PLL, it's proven. Worked fantastic. We, and I mean a few of us, did do all the possible displays back then. Everything from old school mono NTSC, through to component 1080p worked great.
I kind of want to make sure, "Drives everything" is on the spec sheet. Obviously, new school HDMI type digital is out. Converter chips for that. IMHO, it's probably wise to go that route too. Someone can make a board with one on it.
But, with a little work, we can do it all otherwise. From TTL on up, maybe need a level shifter, but maybe not. I picked up a pro display that covers all the old formats, CGA, etc... and all the TV frequency formats, PAL, component, S-video, etc... Got that for a trade too.
That all may just come in handy. Lots of industrial displays out there.
I guess I'm saying, if it's worth it, yeah. An image using a jumper and or switch would make for some testing now, if that circuit warrants it, as it all worked a treat in HOT.
There's a new v31 zip file at the top of this thread which has a new Prop123_A9_Prop2_8cogs_v31.rbf image that uses bit 8 of HUBSET in clock-set mode to shift the DACs down by one pin.
This NTSC file outputs S-video as described in the previous post:
I've got the schematic off to Treehouse now for final layout edits.
Tonight I downloaded the latest process design kit from OnSemi and I've been doing some sanity-check simulations. Things look perfect. Tomorrow I'm going to figure out how to run SOA simulations (safe operating area), to ensure that we are not exceeding current-density limits, which would shorten the life of the chip.
I've got the schematic off to Treehouse now for final layout edits.
Tonight I downloaded the latest process design kit from OnSemi and I've been doing some sanity-check simulations. Things look perfect. Tomorrow I'm going to figure out how to run SOA simulations (safe operating area), to ensure that we are not exceeding current-density limits, which would shorten the life of the chip.
I've been looking at Streamer section of documentation v31 (page 34 onwards) and I have a few comments/questions:
1. Paragraph beginning "There are six instructions" on p. 34 needs amending as only five now.
2. LUT modes (not Goertzel)
The word "palette" is not mentioned once. Are the bbbb bits in effect palette select bits, so there can be at most 16 palettes? Is the base address bbbb00000 added to right-aligned 1/2/4/8 bit value? If so, this wastes some space in the LUT, e.g. there is room for 32 palettes with nibble data.
3. RFLONG LUT modes
The bytes in each long are shifted right, i.e. low byte first, then re-order bit determines shift direction within each byte?
4. Immediate LUT modes
There is no re-order bit so data always shifted right? What does "and the top bits are replicated" mean?
I've got the fastest and slowest timing arcs within our syncronous I/O pad off to OnSemi, so that they can do setup/hold and delay sweeps across nine differeent process-voltage-temperature corners. This is necessary for characterization of our pad "IP", so that it can integrate into their standard-cell synthesis flow.
Also, Treehouse is making final edits to the pad layout, to improve ESD handling and electro-migration limitting.
As of tonight, I'm back on Spin2. Think, there will be a new PNut.exe soon which actually compiles Spin2 code.
Is there a full parameter list for the v31 FPGA versions of HUBSET instruction?
EDIT: I guess all bar the clock/PLL options are as documented. It's the clock options I'm interested in. There used to be a $7F and $FF, was there also a $00?
EDIT2: Never mind. I just had to read more in the docs. It's only $00 for 20 MHz and $FF for 80 MHz now.
Using same code on pins 1 through 4 always gives a non-zero result. I'm software pulsing the OUT line with a OUTH, take a reading, then OUTL, and another reading.
I'm at the same time sampling the neighbour's IN, which is configured to show me what the test pin's state is.
Comments
Hey Chip,
I've not been able to make s-video output work. Would be good to test component too. I just don't have my head wrapped around how to specify these.
If you have a free minute, would you mind a sample color setup for both? Maybe just as comments to the basic TV demo?
We've not actually tested either of these. We should.
I had a big scare overnight. I was looking through some OnSemi process document and I saw current-density guidelines for resistors being 100uA/um. I had designed for 500uA/um, based on some other document, which was way too hot. I contacted OnSemi and, thankfully, they said 500uA/um is actually fine for the RPPOLY resistor that I'm using in the 123.75-ohm fast DAC. I had already redesigned it and was planning on some protracted layout efforts. Fortunately, we don't need to fret about it. Whew!
Np big rush. Rest.
The problem is that the FPGA image doesn't output DAC0, which is Luma for S-Video. It shifts everything down by one, so that we get the three DAC output channels on DAC0, DAC1, and DAC2, while what should be DAC0 is digital P0, used for VGA V-sync. I'll need to make a special image, or, better yet, use some switch on the FPGA board. Are you still using the DE2-115, or do you have a Prop123-A9?
I can use either. Got both.
Ahh, that's the trouble right there! Good to know. What I got after, what I thought was a configuration based on HOT, accounting for the 8 bit DACS, was composite on both channels.
And here's the thing. If that circuit is really just lifted from the HOT chip, and the only real difference is the NCO, instead of PLL, it's proven. Worked fantastic. We, and I mean a few of us, did do all the possible displays back then. Everything from old school mono NTSC, through to component 1080p worked great.
I kind of want to make sure, "Drives everything" is on the spec sheet. Obviously, new school HDMI type digital is out. Converter chips for that. IMHO, it's probably wise to go that route too. Someone can make a board with one on it.
But, with a little work, we can do it all otherwise. From TTL on up, maybe need a level shifter, but maybe not. I picked up a pro display that covers all the old formats, CGA, etc... and all the TV frequency formats, PAL, component, S-video, etc... Got that for a trade too.
That all may just come in handy. Lots of industrial displays out there.
I guess I'm saying, if it's worth it, yeah. An image using a jumper and or switch would make for some testing now, if that circuit warrants it, as it all worked a treat in HOT.
It uses bit 8 of HUBSET in clock-set mode to shift the DACs down by one position:
There's a new v31 zip file at the top of this thread which has a new Prop123_A9_Prop2_8cogs_v31.rbf image that uses bit 8 of HUBSET in clock-set mode to shift the DACs down by one pin.
This NTSC file outputs S-video as described in the previous post:
Tonight I downloaded the latest process design kit from OnSemi and I've been doing some sanity-check simulations. Things look perfect. Tomorrow I'm going to figure out how to run SOA simulations (safe operating area), to ensure that we are not exceeding current-density limits, which would shorten the life of the chip.
I'm looking forward to getting back to Spin2.
1. Paragraph beginning "There are six instructions" on p. 34 needs amending as only five now.
2. LUT modes (not Goertzel)
The word "palette" is not mentioned once. Are the bbbb bits in effect palette select bits, so there can be at most 16 palettes? Is the base address bbbb00000 added to right-aligned 1/2/4/8 bit value? If so, this wastes some space in the LUT, e.g. there is room for 32 palettes with nibble data.
3. RFLONG LUT modes
The bytes in each long are shifted right, i.e. low byte first, then re-order bit determines shift direction within each byte?
4. Immediate LUT modes
There is no re-order bit so data always shifted right? What does "and the top bits are replicated" mean?
Also, Treehouse is making final edits to the pad layout, to improve ESD handling and electro-migration limitting.
As of tonight, I'm back on Spin2. Think, there will be a new PNut.exe soon which actually compiles Spin2 code.
Looking forward to putting Spin2 to the test.
Can you also add command line options for compiling and uploading? This will make it easier to use (and start adding support in) other IDEs/editors.
EDIT: I guess all bar the clock/PLL options are as documented. It's the clock options I'm interested in. There used to be a $7F and $FF, was there also a $00?
EDIT2: Never mind. I just had to read more in the docs. It's only $00 for 20 MHz and $FF for 80 MHz now.
$FF = 80MHZ
$7F = 40MHZ
$3F = 20MHZ
$1F = 10MHZ
$0F = 5MHZ
$01 = RCSLOW ~624KHZ
Using same code on pins 1 through 4 always gives a non-zero result. I'm software pulsing the OUT line with a OUTH, take a reading, then OUTL, and another reading.
I'm at the same time sampling the neighbour's IN, which is configured to show me what the test pin's state is. This IN still works as expected and shows me the issued OUT is arriving at the physical pin (#0) under test.
and here's what pin #0 looks like:
PS: The ASCII art timing diagram shows samples from redirected pins #5 and #1 respectively.
The upper pins are configured differently (for boot and such).
What state is Y[0]?