Just noticed the rad hard comment, if I get a chance I'll run the design through our synthesis tools in the IC process I work with (Unofficially rad-hard). I think I can safely post power estimates and area requirements if anyone is interested without violating our NDA (Though I should probably double check that one).
How does this work? How does the chip architecture affect the radiation hardening?*
* Ok, besides the error correcting logic. I'm thinking more along the lines of radiation hardening tries to avoid having any errors in the first place.
Sorry if this ends up being a duplicate post (my last post didn't seem to work). Some processes are large enough and have thick enough layers to largely avoid radiation effects without adding additional error correction logic. The process I work with is one of those processes but is not officially branded as such. I mostly want to see how much area and power would be used/wasted on a uC design in the DALSA IC process. The rad-hard aspect just struck me as something other people might be interested in.
Just noticed the rad hard comment, if I get a chance I'll run the design through our synthesis tools in the IC process I work with (Unofficially rad-hard). I think I can safely post power estimates and area requirements if anyone is interested without violating our NDA (Though I should probably double check that one).
Chip, what changes have you made to the counters and video?
I've got it all unified under one peripheral which transfers pins to and from hub memory, transfers hub memory to DACs, and performs a DDS/Goertzel operation. It will be a week or so before I'll have an image to post.
I've got it all unified under one peripheral which transfers pins to and from hub memory, transfers hub memory to DACs, and performs a DDS/Goertzel operation. It will be a week or so before I'll have an image to post.
Haha!! Take your time....we're all busy with the P1 verilog now!!
I am surprised anyone is reading the P2 forum... too busy playing P1 FPGA
I wonder if the activity will shift back here once Chip releases a P2 FPGA image? I'll certainly start looking at what is required to update the PropGCC code generator for the new design.
I wonder if the activity will shift back here once Chip releases a P2 FPGA image? I'll certainly start looking at what is required to update the PropGCC code generator for the new design.
Sure it will because most of us have some form of attention deficit disorder!
I've got it all unified under one peripheral which transfers pins to and from hub memory, transfers hub memory to DACs, and performs a DDS/Goertzel operation. It will be a week or so before I'll have an image to post.
I wonder if the activity will shift back here once Chip releases a P2 FPGA image? I'll certainly start looking at what is required to update the PropGCC code generator for the new design.
Yes, of course it most certainly will but we will only have the P2 image whereas we have P1 design files that we may play with to see if something else might be possible that could be incorporated into P2 perhaps? But I imagine that most of the work will be on testing P2 and developing our tools and software. I will look at running my own macro-assembler at least which will enable me to simplify my VM source and lay it out much better than the Spin tool can. All this is so exciting!!!
Yes, of course it most certainly will but we will only have the P2 image whereas we have P1 design files that we may play with to see if something else might be possible that could be incorporated into P2 perhaps? But I imagine that most of the work will be on testing P2 and developing our tools and software. I will look at running my own macro-assembler at least which will enable me to simplify my VM source and lay it out much better than the Spin tool can. All this is so exciting!!!
I've been waiting for you to announce that you plan to implement the Tachyon VM in hardware on the P1. :-)
I've been waiting for you to announce that you plan to implement the Tachyon VM in hardware on the P1. :-)
In that case I'd have to start from scratch I guess and it wouldn't be much use unless it was in production form! No, I'd be happy with the P2 and I'm sure that all of us together will be able to really utilize the P2 in a much shorter time than the P1 took, for a whole lot of reasons. So this would mean that we would need to have a P2 OBEX setup too. With the various languages and environments and tools this should be pretty awesome in a short space of time, perhaps even before the P2 is available in silicon. What a boost.
In that case I'd have to start from scratch I guess and it wouldn't be much use unless it was in production form! No, I'd be happy with the P2 and I'm sure that all of us together will be able to really utilize the P2 in a much shorter time than the P1 took, for a whole lot of reasons. So this would mean that we would need to have a P2 OBEX setup too. With the various languages and environments and tools this should be pretty awesome in a short space of time, perhaps even before the P2 is available in silicon. What a boost.
I thought it might be interesting to have a minimal just good enough prop 1 with your forth and a master APB interface for FPGA development. It would probably be relatively simple to do - if only I had more time… What would be the minimal cog count - just 1? I'm assuming it would just have forth in RAM at reset time so no need for the Parallax loader etcetera, but that would just be a question of how the "ROM" is initialized.
I wonder if the activity will shift back here once Chip releases a P2 FPGA image? I'll certainly start looking at what is required to update the PropGCC code generator for the new design.
Now that we don't have multi-tasking on P2 I have to do it myself!
(a) DE2 for P2 development
(b) DE0 for P1V development.
Which one will I play with today? I Can't decide so it looks like both!
Fun...fun...fun!
I've lost track of what's going on with counters and video...
I think that maybe the old counters are gone and some functions moved to the new "smart pins".
Analog video will now be supported by direct transfer from HUB memory to groups of 4 pins for RGB (VGA) video at HD resolution.
I think Chip mentioned support for things like 24-bit digital video output too.
But, I could be wrong...
I've lost track of what's going on with counters and video...
I think that maybe the old counters are gone and some functions moved to the new "smart pins".
Analog video will now be supported by direct transfer from HUB memory to groups of 4 pins for RGB (VGA) video at HD resolution.
I think Chip mentioned support for things like 24-bit digital video output too.
But, I could be wrong...
I think that's right.
The last plan I heard was to move the old counters into the Smart Pins, which expand with things like True PWM, Quadrature, and capture. (and serial ? hopefully QuadSPI ?)
Undefined yet is if those smart-cells are per pin, or per pairs of pins.
The new HUB access will include an in line CLUT at fSys/N ( iirc Chip has NCO (option?) here ).
Once all that can stream wide video to DACs at fSys, allowing LCD style digital out is a logical extension.
Does anyone recall when Chip said the P2 FPGA image would be available? I recall that he posted a week or two ago that it would available soon. I tried to find his latest post about the P2, but all his recent posts have been about the P1 FPGA.
I've got it all unified under one peripheral which transfers pins to and from hub memory, transfers hub memory to DACs, and performs a DDS/Goertzel operation. It will be a week or so before I'll have an image to post.
Silly me told him to take his time since we were all busy with the P1 verilog!
Week after next. He was close to a week away, when Ken announced he would be answering questions about P1 this week. Since next week, he's supposed to get back on P2, maybe the week after is a reasonable, early expectation.
Silly me told him to take his time since we were all busy with the P1 verilog!
Yes, that's probably the one I'm thinking about. The P1 verilog is nice, but I would much rather have seen the P2 image by Monday. So now we have to wait 2 more weeks for the P2? These delays are becoming almost unbearable.
Things like PWM and ADC accumulation are moving into the smart pins. Inside each cog there is an NCO-driven shifter/DDS circuit that is good for transferring pins to and from the hub quickly, moving data through DACs (video), and performing DDS/Goertzel operations.
The DDS/Goertzel circuit outputs a sine (and cosine, if you want) and then correlates the sine and cosine with an incoming ADC bitstream to ultimately perform I-Q demodulation. This is good for making all kinds of measurements involving sine waves traveling through the real world. Sine waves are to nature what square waves are to logic. There's no need to do anything with the I-Q data. You could just use the DDS circuit to output a custom waveform of any frequency, up to Fclk/2, or 100MHz in the case of a 200MHz clock.
Here are the notes I've been making for the implementation:
Things like PWM and ADC accumulation are moving into the smart pins. Inside each cog there is an NCO-driven shifter/DDS circuit that is good for transferring pins to and from the hub quickly, moving data through DACs (video), and performing DDS/Goertzel operations.
The DDS/Goertzel circuit outputs a sine (and cosine, if you want) and then correlates the sine and cosine with an incoming ADC bitstream to ultimately perform I-Q demodulation. This is good for making all kinds of measurements involving sine waves traveling through the real world. Sine waves are to nature what square waves are to logic. There's no need to do anything with the I-Q data. You could just use the DDS circuit to output a custom waveform of any frequency, up to Fclk/2, or 100MHz in the case of a 200MHz clock.
Here are the notes I've been making for the implementation:
With the DDS/Goertzel circuit I could probably make a audio pitch detector by out putting the desired signal on one cog and inputting the test signal on another cog and comparing the two. :cool:
The DDS/Goertzel circuit outputs a sine (and cosine, if you want) and then correlates the sine and cosine with an incoming ADC bitstream to ultimately perform I-Q demodulation.
This strikes very close to home... Sounds absolutely fantastic!
Comments
How does this work? How does the chip architecture affect the radiation hardening?*
* Ok, besides the error correcting logic. I'm thinking more along the lines of radiation hardening tries to avoid having any errors in the first place.
Perhaps Delus is about to discover that the Propeller MCU is actually a really good design choice for the harsh radiation environment of space!
It would behave like a pseudo-random sequencer.
Chip, what changes have you made to the counters and video?
I've got it all unified under one peripheral which transfers pins to and from hub memory, transfers hub memory to DACs, and performs a DDS/Goertzel operation. It will be a week or so before I'll have an image to post.
Haha!! Take your time....we're all busy with the P1 verilog now!!
Sure it will because most of us have some form of attention deficit disorder!
That all sounds very exciting
Yes, of course it most certainly will but we will only have the P2 image whereas we have P1 design files that we may play with to see if something else might be possible that could be incorporated into P2 perhaps? But I imagine that most of the work will be on testing P2 and developing our tools and software. I will look at running my own macro-assembler at least which will enable me to simplify my VM source and lay it out much better than the Spin tool can. All this is so exciting!!!
In that case I'd have to start from scratch I guess
I thought it might be interesting to have a minimal just good enough prop 1 with your forth and a master APB interface for FPGA development. It would probably be relatively simple to do - if only I had more time… What would be the minimal cog count - just 1? I'm assuming it would just have forth in RAM at reset time so no need for the Parallax loader etcetera, but that would just be a question of how the "ROM" is initialized.
- DE2-115 + 2x DE0-Nano's are for P2 development
- 2x BEMICRO CV's + 1x DE0-Nano will be for P1V development
(a) DE2 for P2 development
(b) DE0 for P1V development.
Which one will I play with today? I Can't decide so it looks like both!
Fun...fun...fun!
I think that maybe the old counters are gone and some functions moved to the new "smart pins".
Analog video will now be supported by direct transfer from HUB memory to groups of 4 pins for RGB (VGA) video at HD resolution.
I think Chip mentioned support for things like 24-bit digital video output too.
But, I could be wrong...
I think that's right.
The last plan I heard was to move the old counters into the Smart Pins, which expand with things like True PWM, Quadrature, and capture. (and serial ? hopefully QuadSPI ?)
Undefined yet is if those smart-cells are per pin, or per pairs of pins.
The new HUB access will include an in line CLUT at fSys/N ( iirc Chip has NCO (option?) here ).
Once all that can stream wide video to DACs at fSys, allowing LCD style digital out is a logical extension.
That may not be any-pin mapped ?
Silly me told him to take his time since we were all busy with the P1 verilog!
The DDS/Goertzel circuit outputs a sine (and cosine, if you want) and then correlates the sine and cosine with an incoming ADC bitstream to ultimately perform I-Q demodulation. This is good for making all kinds of measurements involving sine waves traveling through the real world. Sine waves are to nature what square waves are to logic. There's no need to do anything with the I-Q data. You could just use the DDS circuit to output a custom waveform of any frequency, up to Fclk/2, or 100MHz in the case of a 200MHz clock.
Here are the notes I've been making for the implementation:
With the DDS/Goertzel circuit I could probably make a audio pitch detector by out putting the desired signal on one cog and inputting the test signal on another cog and comparing the two. :cool:
This strikes very close to home... Sounds absolutely fantastic!