Well, it's done. I never thought I'd have so much trouble editing a bitmap. You know what, Gimp sucks for making diagrams with!
I finally gave up and started looking for an alternative and found a rather interesting tool in Calligra Flow. It had some of it's own idiosyncrasies and crashed on occasion but I mostly enjoyed using it, partly due to it's excellent auto-save feature.
Attached is both the odg edit file and a png of the result.
FRQA would be set to $1 and CTRMODEA would be something like %01000 (Or maybe %11010, what's the diff between these two?). Basically, increment PHSA when and while APIN is high. This will be what Chip is doing already with the internal A/Ds.
CTRMODEB would be %1111111. Note the extra leading bit, I added that in for the control of extra mux. This makes PHSB always integrate the output of PHSA.
Then the software just has to periodically, say every 1024 clocks, read the value of PHSB and perform a double differential on it. And that's your completed second order 1-bit sampler. Well, there is probably something special in the modulator side of things too but I don't know nothing there.
Process change. A resynthesis will be necessary. Chip is folding in some changes and observations made during FPGA testing prior to submitting the new design. The Chip to Chip comms feature was removed and replaced by some serial communications hardware added to the COGS. Turns out, chip level feature complicate clocking in ways that COG features do not.
Come to think of it, I can't recall any discussion confirming that move or a move away. IMHO, it's likely they are still on the path, or are currently evaluating. In any case, before the next synthesis run is done, they will need to have settled on that.
Given some of the banter here, it's also likely that Chip and some people he's talking to regularly about the project are thinking about how to better optimize things. An example was the serializer being moved from a chip level feature to a COG level one and how that impacted clocking and circuit paths in a positive way.
A lot like the DE0 and DE2 emulations that are available and documented in other threads but faster and more awesome.
I looked at some other threads and noticed they are using FPGA boards to emulate the Propeller 2. Is this correct? I also did some research on FPGA's in general and, well they sound really cool and a nice piece of technology, but how in the world do you program the thing? I'm seeing a lot of professional ($$$) software but not much in the way of something suiting the hobbyist.
The Prop2 is anywhere from 9 to 12 months away as it goes through a resynthesis. Maybe 9 months to prototype chips, and a couple months after that for production units.
In the meantime people have been using the TeraASIC DE0 and DE2 boards to emulate parts of the Prop2. This is also how Parallax is simulating the design, and developing software.
For small boards most FPGA software is usually free for download, especially if all you need is the FGPA configuration program. There are also some add on boards that have been designed to connect either SDRAM or VGA. So you can join this fun if you want to get one of the emulator boards.
The Prop2 is anywhere from 9 to 12 months away as it goes through a resynthesis. Maybe 9 months to prototype chips, and a couple months after that for production units.
Hey Bruce,
Two thoughts - first, better not be that long! Second, we are in receipt of the schedule and proposal from both synthesis firm and fabricator. The lead time for obtaining the next set of prototype chips is much shorter than stated above, provided Chip closes up the design optimization process by December. We could have prototypes more closely to 6- or 7-months from today pending completion by Chip.
While the synthesis and fab times are long, they're also somewhat accurate estimates. Just add 25% more time to what the sales person says and you've got the real date.
But I've learned my lesson. These time estimates mean nothing in our situation - both mine (and yours). What matters is that we're in it to finish it, and that we run a business to support it.
This is a great thread. About once a month I drop in and see what the latest is. Though I am sad to see the resynthesis, I am loving all these geeky engineering details. This is "reality TV" for the engineer. Keep up the openness Parallax!
What would you guys think about the addition of 4 new registers DIFA/DIFB/DIFC/DIFD which track pin changes? The cog register map would then look like this:
These DIFx registers would show 1's for pins that have changed. By writing 1's, you clear their state (unless a pin change was happening at the same instant, in which case the state would remain set). These change-sensing flops would be in the hub circuitry to minimize the flip-flop count.
This would solve the nagging problem of potentially missing pin state changes.
What would you guys think about the addition of 4 new registers DIFA/DIFB/DIFC/DIFD which track pin changes? The cog register map would then look like this:
These DIFx registers would show 1's for pins that have changed. By writing 1's, you clear their state (unless a pin change was happening at the same instant, in which case the state would remain set). These change-sensing flops would be in the hub circuitry to minimize the flip-flop count.
This would solve the nagging problem of potentially missing pin state changes.
Looks interesting - I assume we don't have to wait for hub cycles? (ie 1 cycle not 8 cycle access to DIFx) - it would be very useful for handling pseudo-interrupts, not missing messages etc
I'd probably order the registers as INDx, INx, OUTx, DIRx, DIFx to more closely match the P1 layout.
A quick request - next loadables, could you make a nano config that does not need the add-on board? I am thinking of trying your 32 bit addressed serial between my DE2-115 and two nano's...
What would you guys think about the addition of 4 new registers DIFA/DIFB/DIFC/DIFD which track pin changes? The cog register map would then look like this:
These DIFx registers would show 1's for pins that have changed. By writing 1's, you clear their state (unless a pin change was happening at the same instant, in which case the state would remain set). These change-sensing flops would be in the hub circuitry to minimize the flip-flop count.
This would solve the nagging problem of potentially missing pin state changes.
What would you guys think about the addition of 4 new registers DIFA/DIFB/DIFC/DIFD which track pin changes? The cog register map would then look like this:
These DIFx registers would show 1's for pins that have changed. By writing 1's, you clear their state (unless a pin change was happening at the same instant, in which case the state would remain set). These change-sensing flops would be in the hub circuitry to minimize the flip-flop count.
This would solve the nagging problem of potentially missing pin state changes.
Can they also work on one chosen edge, and co-operate with a WAIT opcode, so users can wait on a Rise or Fall, in one line ?
Can they also work on one chosen edge, and co-operate with a WAIT opcode, so users can wait on a Rise or Fall, in one line ?
Good idea! Let me see what I can do. I'm thinking of just having them accessible via jump-if-changed instructions, and not spend precious register space on them.
Good idea! Let me see what I can do. I'm thinking of just having them accessible via jump-if-changed instructions, and not spend precious register space on them.
Good idea! Let me see what I can do. I'm thinking of just having them accessible via jump-if-changed instructions, and not spend precious register space on them.
What would you guys think about the addition of 4 new registers DIFA/DIFB/DIFC/DIFD which track pin changes?
Forgive me for my lack of P2 knowledge, but if the pin registers (INA/INB/INC/IND) are implemented similarly to the INA(/INB) registers on the Propeller 1, (i.e. with shadow-RAM), wouldn't it be easier to implement an INSTRUCTION (instead of extra registers) to detect changes in input pins? The instruction would compare the shadow-RAM value of the INx register with the actual value, and would conditionally jump to another location based on a mask of bits that you want to test against changes.
Actually you would need two instructions: one for each condition (same of different). Let's call it TJIM - Test and Jump if Input Modified and TJIS - Test and Jump if Input Same.
No wait, you'd need 8 instructions: two for each port INA/INB/INC/IND.
On second thought, this would probably take up a lot of instruction space in order to save 4 memory longs. Never mind, carry on :-)
I am in the middle of coding I/O on the P2 to do USB FS. At 80MHz it is quite difficult just to read the pins without any serial/shifter help. And this is for 12MHz signalling.
I think the ideas are great, but I would like to ponder a little longer. So I am going to reserve my input until a little later today, after I look and see what would be a big help for this.
Really interesting idea, jac_goudsmit. Something like that wouldn't even require any more flip-flops. I'll see what I can do there. Wait.. I just realized that it wouldn't catch intervening events, so it's not going to be a solution to the did-a-change-happen? problem.
I abandoned the course I was on with the extra registers - too big and messy. Instead, I exploited an input-pin mux that was already present for the pin instructions and made an edge detector that stalls the pipeline until the desired edge event occurs. These are only for single-task programs that need to have perfect registration to external (pins) or internal (XCH) events edge events:
WAITPOS D/#n 'specify pin and wait for positive edge
WAITNEG D/#n 'specify pin and wait for negative edge
They work beautifully. They turn the cog into an edge-triggered flip-flop, which jmg would appreciate. These are way simpler to use than WAITPEQ/WAITPNE would be, and they detect the edge event, not just states, so one of them does the trick.
I think these two instructions will make fast XCH comms a snap. Using these to frame nibble/byte/word moves over I/O pins should make fast inter-Prop2 comms possible, too.
I am in the middle of coding I/O on the P2 to do USB FS. At 80MHz it is quite difficult just to read the pins without any serial/shifter help. And this is for 12MHz signalling.
A simple serial shifter is not going to be too much help for USB, as you should ideally edge-resync, but a shifter that can phase-adjust could be worth having.
You may be able to emulate such a shifter with Counter clocking an external HC device ? (as proof of concept)
One thread, or stub, could manage edge-sync checking, and counter nudges.
Another approach is to code for 1.5MHz and use threads to prove what HW features are needed.
WAITPOS D/#n 'specify pin and wait for positive edge
WAITNEG D/#n 'specify pin and wait for negative edge
They work beautifully. They turn the cog into an edge-triggered flip-flop, which jmg would appreciate. These are way simpler to use than WAITPEQ/WAITPNE would be, and they detect the edge event, not just states, so one of them does the trick.
I think these two instructions will make fast XCH comms a snap. Using these to frame nibble/byte/word moves over I/O pins should make fast inter-Prop2 comms possible, too.
I abandoned the course I was on with the extra registers - too big and messy. Instead, I exploited an input-pin mux that was already present for the pin instructions and made an edge detector that stalls the pipeline until the desired edge event occurs. These are only for single-task programs that need to have perfect registration to external (pins) or internal (XCH) events edge events:
WAITPOS D/#n 'specify pin and wait for positive edge
WAITNEG D/#n 'specify pin and wait for negative edge
Is there also a matching 'wait on change' (aka wait on either edge) ?
Are these sticky, (so you would not miss an edge), or simply 'run-live' ie looking at the XOR of 2 D-FF's ?
Does this totally exclude threads, or just stall other threads, so they would 'slow down' by the extend of actual time spent waiting on the edge(s). Such controlled disturbance could be tolerated in many applications.
Is there also a matching 'wait on change' (aka wait on either edge) ?
Does this totally exclude threads, or just stall other threads, so they would 'slow down' by the extend of actual time spent waiting on the edge(s). Such controlled disturbance could be tolerated in many applications.
You are right there..
These instructions completely stall the pipeline and are not useful for multi-tasking. What the cog can do afterwards on the pins, though, looks like hardware on the scope - perfect timing. I didn't make an any-edge version, because it seemed practically useless. If you want to trigger on both edges, you can use alternating WAITPOS/WAITNEG's. I went through a long mental exercise when designing the counters and determined that counting either negative or positive edges was useful, but counting all edges was superfluous, or even sloppy.
Comments
I finally gave up and started looking for an alternative and found a rather interesting tool in Calligra Flow. It had some of it's own idiosyncrasies and crashed on occasion but I mostly enjoyed using it, partly due to it's excellent auto-save feature.
Attached is both the odg edit file and a png of the result.
CTRMODEB would be %1111111. Note the extra leading bit, I added that in for the control of extra mux. This makes PHSB always integrate the output of PHSA.
Then the software just has to periodically, say every 1024 clocks, read the value of PHSB and perform a double differential on it. And that's your completed second order 1-bit sampler.
The relevant links:
http://forums.parallax.com/showthread.php/125543-Propeller-II-update-BLOG?p=1206810&viewfull=1#post1206810
http://forums.parallax.com/showthread.php/125543-Propeller-II-update-BLOG?p=1209077&viewfull=1#post1209077
http://forums.parallax.com/showthread.php/125543-Propeller-II-update-BLOG?p=1209141&viewfull=1#post1209141
http://forums.parallax.com/showthread.php/150588-Big-update-for-DE2-115-and-DE0-Nano-users-w-add-on-boards
EDIT: Ah, found it - http://forums.parallax.com/showthread.php/125543-Propeller-II-update-BLOG?p=1207152&viewfull=1#post1207152
I don't know if Parallax is still on that path, of shifting to OnSemi, or not ...
Given some of the banter here, it's also likely that Chip and some people he's talking to regularly about the project are thinking about how to better optimize things. An example was the serializer being moved from a chip level feature to a COG level one and how that impacted clocking and circuit paths in a positive way.
Lots of fun!
Well worth the wait.
A lot like the DE0 and DE2 emulations that are available and documented in other threads but faster and more awesome.
I looked at some other threads and noticed they are using FPGA boards to emulate the Propeller 2. Is this correct? I also did some research on FPGA's in general and, well they sound really cool and a nice piece of technology, but how in the world do you program the thing? I'm seeing a lot of professional ($$$) software but not much in the way of something suiting the hobbyist.
The Prop2 is anywhere from 9 to 12 months away as it goes through a resynthesis. Maybe 9 months to prototype chips, and a couple months after that for production units.
In the meantime people have been using the TeraASIC DE0 and DE2 boards to emulate parts of the Prop2. This is also how Parallax is simulating the design, and developing software.
For small boards most FPGA software is usually free for download, especially if all you need is the FGPA configuration program. There are also some add on boards that have been designed to connect either SDRAM or VGA. So you can join this fun if you want to get one of the emulator boards.
Hey Bruce,
Two thoughts - first, better not be that long! Second, we are in receipt of the schedule and proposal from both synthesis firm and fabricator. The lead time for obtaining the next set of prototype chips is much shorter than stated above, provided Chip closes up the design optimization process by December. We could have prototypes more closely to 6- or 7-months from today pending completion by Chip.
While the synthesis and fab times are long, they're also somewhat accurate estimates. Just add 25% more time to what the sales person says and you've got the real date.
But I've learned my lesson. These time estimates mean nothing in our situation - both mine (and yours). What matters is that we're in it to finish it, and that we run a business to support it.
Just a point of clarification here - there are currently two, soon to be three "DE2" boards, and the original DE2 (cyclone ii) *isn't* the one we use.
We use the DE2-115 (cyclone iv) which is bigger, newer, and not much more expensive.
There is also a DE2i-150 in the pipeline
http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=13&List=Simple#Category139
$000..$1ED: RAM
$1EE: INDA
$1EF: INDB
$1F0: DIFA
$1F1: DIFB
$1F2: DIFC
$1F3: DIFD
$1F4: INA
$1F5: INB
$1F6: INC
$1F7: IND
$1F8: OUTA
$1F9: OUTB
$1FA: OUTC
$1FB: OUTD
$1FC: DIRA
$1FD: DIRB
$1FE: DIRC
$1FF: DIRD
These DIFx registers would show 1's for pins that have changed. By writing 1's, you clear their state (unless a pin change was happening at the same instant, in which case the state would remain set). These change-sensing flops would be in the hub circuitry to minimize the flip-flop count.
This would solve the nagging problem of potentially missing pin state changes.
In My opinion Good addition.
For all types of State operation programs
Should be useful in conjunction with the PIN D intercog signalling too
I'd probably order the registers as INDx, INx, OUTx, DIRx, DIFx to more closely match the P1 layout.
A quick request - next loadables, could you make a nano config that does not need the add-on board? I am thinking of trying your 32 bit addressed serial between my DE2-115 and two nano's...
Can they also work on one chosen edge, and co-operate with a WAIT opcode, so users can wait on a Rise or Fall, in one line ?
Good idea! Let me see what I can do. I'm thinking of just having them accessible via jump-if-changed instructions, and not spend precious register space on them.
In my opinion ---- Don't use Wait_on that lose instruction before condition is meet.
But I think that is good way to go --- jump-if-changed else Execute-if-NOT-changed conditions
waitpr ' wait for pin rise
waitpf ' wait for pin fall
Been wanting a simple minded interrupt for a looooong time ! Now I can (choose) to make my code much more responsive !
YEEESSSSSS !!!
Cheers,
Peter (pjv)
Don't say "interrupt". That word is banned around here.
Say "event driven". Which is what you always wanted anyway.
It's just a case of having the right events for your threads to wait on.
Forgive me for my lack of P2 knowledge, but if the pin registers (INA/INB/INC/IND) are implemented similarly to the INA(/INB) registers on the Propeller 1, (i.e. with shadow-RAM), wouldn't it be easier to implement an INSTRUCTION (instead of extra registers) to detect changes in input pins? The instruction would compare the shadow-RAM value of the INx register with the actual value, and would conditionally jump to another location based on a mask of bits that you want to test against changes.
Actually you would need two instructions: one for each condition (same of different). Let's call it TJIM - Test and Jump if Input Modified and TJIS - Test and Jump if Input Same.
No wait, you'd need 8 instructions: two for each port INA/INB/INC/IND.
On second thought, this would probably take up a lot of instruction space in order to save 4 memory longs. Never mind, carry on :-)
===Jac
I think the ideas are great, but I would like to ponder a little longer. So I am going to reserve my input until a little later today, after I look and see what would be a big help for this.
I abandoned the course I was on with the extra registers - too big and messy. Instead, I exploited an input-pin mux that was already present for the pin instructions and made an edge detector that stalls the pipeline until the desired edge event occurs. These are only for single-task programs that need to have perfect registration to external (pins) or internal (XCH) events edge events:
WAITPOS D/#n 'specify pin and wait for positive edge
WAITNEG D/#n 'specify pin and wait for negative edge
They work beautifully. They turn the cog into an edge-triggered flip-flop, which jmg would appreciate. These are way simpler to use than WAITPEQ/WAITPNE would be, and they detect the edge event, not just states, so one of them does the trick.
I think these two instructions will make fast XCH comms a snap. Using these to frame nibble/byte/word moves over I/O pins should make fast inter-Prop2 comms possible, too.
A simple serial shifter is not going to be too much help for USB, as you should ideally edge-resync, but a shifter that can phase-adjust could be worth having.
You may be able to emulate such a shifter with Counter clocking an external HC device ? (as proof of concept)
One thread, or stub, could manage edge-sync checking, and counter nudges.
Another approach is to code for 1.5MHz and use threads to prove what HW features are needed.
Magic!
Very cool!
Is there also a matching 'wait on change' (aka wait on either edge) ?
Are these sticky, (so you would not miss an edge), or simply 'run-live' ie looking at the XOR of 2 D-FF's ?
Does this totally exclude threads, or just stall other threads, so they would 'slow down' by the extend of actual time spent waiting on the edge(s). Such controlled disturbance could be tolerated in many applications.
These instructions completely stall the pipeline and are not useful for multi-tasking. What the cog can do afterwards on the pins, though, looks like hardware on the scope - perfect timing. I didn't make an any-edge version, because it seemed practically useless. If you want to trigger on both edges, you can use alternating WAITPOS/WAITNEG's. I went through a long mental exercise when designing the counters and determined that counting either negative or positive edges was useful, but counting all edges was superfluous, or even sloppy.