JMPTASK currently only affects tasks' PCs. The tasks' Z/C flags are unchanged by JMPTASK.
It seems that JMPTASK should at least set them to a known state. If you do hook it up to S[31:30], then the current usage will be the same as implicitly clearing the flags. Allowing JMPTASK to explicitly set those bits would also allow for simple 2-bit parameters to be passed to the task. For instance, an async continuation callback could use the C flag to indicate the success of an async request.
It seems that JMPTASK should at least set them to a known state. If you do hook it up to S[31:30], then the current usage will be the same as implicitly clearing the flags. Allowing JMPTASK to explicitly set those bits would also allow for simple 2-bit parameters to be passed to the task. For instance, an async continuation callback could use the C flag to indicate the success of an async request.
I'll make JMPTASK affect the flags, too.
Maybe what we really need is an instruction to swap Z/C/PC of any task with a register. That would take care of everything at once. The only rule would be: don't use REPS/REPD/TLOCK in the task that is going to be redirected.
Do the LOCKxxx instructions still use the simple round-robin arbitration, or do they also benefit from the "work stealing" round-robin that's been added for hub memory?
Do the LOCKxxx instructions still use the simple round-robin arbitration, or do they also benefit from the "work stealing" round-robin that's been added for hub memory?
They are the same as Prop1, currently. And I'm not sure what you mean about the hub memory, but cogs are still only using their own hub cycles.
They are the same as Prop1, currently. And I'm not sure what you mean about the hub memory, but cogs are still only using their own hub cycles.
Oh! I thought cogs could now access hub memory more frequently than every 8 clocks. Never mind, then. I guess this means the 8-clock rule still applies for all hub resources.
Breaking the 8-clock rule was always a big ask. There is a lot of shuffling already going on in that area and we've got such a lot of bandwidth available already. Be happy.
I suspect that feature is less important now that the WIDE instructions exist. If you do decide to implement it, take a look at my recent blog entry. I don't know if my approach works with your design, but you may find it helpful nonetheless.
Breaking the 8-clock rule was always a big ask. There is a lot of shuffling already going on in that area and we've got such a lot of bandwidth available already. Be happy.
If you get a chance you might want to try running some code under spinsim. It can show all of the wait cycles due to hub accesses, along with the unused cycles due to invalidated instructions after jumps. The use of delayed jumps will help to reduce the amount of invalidated instructions, but it might be difficult to consistently hit the hub slot with code that does a lot of random hub accesses. Hub sharing would be very useful for that kind of code.
EDIT: If you try spinsim use the first version that I posted, which doesn't support the hub exec mode. It seems that the latest version is incorrectly generating hub waits for some instructions.
Thanks for this, by the way! I finally got around to firing up the Feb 6 build! One additional note (which others may have already noted elsewhere): The RX/TX pins on the Prop Plug will plug in to the DE0 board directly. So without any additional wires, anyone with a DE0 and a Prop Plug can at least run the monitor. Just follow ctwardell's diagram for matching up the RX/TX pins. No need to plug in GND/RST.
[FONT=Arial, Tahoma, Verdana, Geneva, sans-serif]Is their anything special required to get the monitor to work with this version?[/FONT]
[FONT=Arial, Tahoma, Verdana, Geneva, sans-serif]Everything else seems to work but I don't get any response from the monitor. I remember that I had to remove the memory chip in a earlier version to get it to work but that's been corrected in this version .[/FONT]
re:I've got the same configuration. I never put my memory chip back in. I can try it with the chip later tonight to see if/how it works.
I haven't put the chip back in mine either, not yet.. Does it currently work with the chip out?
Hi Bob
I have a DE0 with the latest build (feb 6) + add on board + prop plug and no flash chip installed.
Monitor works fine with PST from 600 baud to 460800 baud.
Cheers
Brian
re:I have a DE0 with the latest build (feb 6) + add on board + prop plug and no flash chip installed.
Ok great!! that's what I needed to know. I'll check the monitor code to see if the pin setup changed.
re:I have a DE0 with the latest build (feb 6) + add on board + prop plug and no flash chip installed.
Ok great!! that's what I needed to know. I'll check the monitor code to see if the pin setup changed.
Bob
There may be a bug in the monitor on the last release. It doesn't process hex that you type. It's something trivial, I'm sure, and the next release will have it fixed. The monitor DOES come up, though.
Comments
Found 18 bits CRS function.
Maybe it can help with made CRC for USB and more
// 18-bit CRC polynomial calculator function [17:0] crc18gen ; input [ 9:0] i ; input [17:0] c ; begin crc18gen[0] = c[10] ; crc18gen[1] = c[11] ; crc18gen[2] = c[12] ; crc18gen[3] = i[0] ^ c[0] ^ c[13] ; crc18gen[4] = i[0] ^ i[1] ^ c[0] ^ c[1] ^ c[14] ; crc18gen[5] = i[1] ^ i[2] ^ c[1] ^ c[2] ^ c[15] ; crc18gen[6] = i[2] ^ i[3] ^ c[2] ^ c[3] ^ c[16] ; crc18gen[7] = i[3] ^ i[4] ^ c[3] ^ c[4] ^ c[17] ; crc18gen[8] = i[0] ^ i[4] ^ i[5] ^ c[0] ^ c[4] ^ c[5] ; crc18gen[9] = i[1] ^ i[5] ^ i[6] ^ c[1] ^ c[5] ^ c[6] ; crc18gen[10] = i[2] ^ i[6] ^ i[7] ^ c[2] ^ c[6] ^ c[7] ; crc18gen[11] = i[3] ^ i[7] ^ i[8] ^ c[3] ^ c[7] ^ c[8] ; crc18gen[12] = i[4] ^ i[8] ^ i[9] ^ c[4] ^ c[8] ^ c[9] ; crc18gen[13] = i[5] ^ i[9] ^ c[5] ^ c[9] ; crc18gen[14] = i[6] ^ c[6] ; crc18gen[15] = i[7] ^ c[7] ; crc18gen[16] = i[8] ^ c[8] ; crc18gen[17] = i[9] ^ c[9] ; end endfunctionIt seems that JMPTASK should at least set them to a known state. If you do hook it up to S[31:30], then the current usage will be the same as implicitly clearing the flags. Allowing JMPTASK to explicitly set those bits would also allow for simple 2-bit parameters to be passed to the task. For instance, an async continuation callback could use the C flag to indicate the success of an async request.
I'll make JMPTASK affect the flags, too.
Maybe what we really need is an instruction to swap Z/C/PC of any task with a register. That would take care of everything at once. The only rule would be: don't use REPS/REPD/TLOCK in the task that is going to be redirected.
Thanks for finding this, Sapieha.
As You can read in 1 row of Code.
// 18-bit CRC polynomial calculator
One more version with CRC 16
/////////////////////////////////////////////////////////////////////// // File: CRC16.v // Verilog module containing a synthesizable CRC function /////////////////////////////////////////////////////////////////////// module CRC16( input [ 7:0] D, output [15:0] C ); // polynomial: (0 5 12 16) // data width: 8 // convention: the first serial data bit is D[7] always @(D, C) begin end assign C[0] = D[4] ^ D[0] ^ C[8] ^ C[12]; assign C[1] = D[5] ^ D[1] ^ C[9] ^ C[13]; assign C[2] = D[6] ^ D[2] ^ C[10] ^ C[14]; assign C[3] = D[7] ^ D[3] ^ C[11] ^ C[15]; assign C[4] = D[4] ^ C[12]; assign C[5] = D[5] ^ D[4] ^ D[0] ^ C[8] ^ C[12] ^ C[13]; assign C[6] = D[6] ^ D[5] ^ D[1] ^ C[9] ^ C[13] ^ C[14]; assign C[7] = D[7] ^ D[6] ^ D[2] ^ C[10] ^ C[14] ^ C[15]; assign C[8] = D[7] ^ D[3] ^ C[0] ^ C[11] ^ C[15]; assign C[9] = D[4] ^ C[1] ^ C[12]; assign C[10] = D[5] ^ C[2] ^ C[13]; assign C[11] = D[6] ^ C[3] ^ C[14]; assign C[12] = D[7] ^ D[4] ^ D[0] ^ C[4] ^ C[8] ^ C[12] ^ C[15]; assign C[13] = D[5] ^ D[1] ^ C[5] ^ C[9] ^ C[13]; assign C[14] = D[6] ^ D[2] ^ C[6] ^ C[10] ^ C[14]; assign C[15] = D[7] ^ D[3] ^ C[7] ^ C[11] ^ C[15]; endmoduleAs You can read in code.
// polynomial: (0 5 12 16)
// data width: 8
// convention: the first serial data bit is D[7]
What is the result of CRC over this string "123456789" ?
Read this and look on diferences
http://en.wikipedia.org/wiki/Cyclic_redundancy_check
http://srecord.sourceforge.net/crc16-ccitt.html
On this site You can generate correct verilog else VHDL code for any of CRC needed for USB --- and much more
http://www.easics.com/webtools/crctool
Ps. this site have both protocols for USB 5 and 16 bits.
Defined in firtst part by SET
They are the same as Prop1, currently. And I'm not sure what you mean about the hub memory, but cogs are still only using their own hub cycles.
Oh! I thought cogs could now access hub memory more frequently than every 8 clocks. Never mind, then. I guess this means the 8-clock rule still applies for all hub resources.
I just haven't gotten there yet.
I suspect that feature is less important now that the WIDE instructions exist. If you do decide to implement it, take a look at my recent blog entry. I don't know if my approach works with your design, but you may find it helpful nonetheless.
EDIT: If you try spinsim use the first version that I posted, which doesn't support the hub exec mode. It seems that the latest version is incorrectly generating hub waits for some instructions.
http://www.easics.com/webtools/crctool
The website was very slow to generate the code but it was fun to generate it in both Verilog and VHDl to compare them. :cool:
Good PDF on CRC standards
Thanks for this, by the way! I finally got around to firing up the Feb 6 build! One additional note (which others may have already noted elsewhere): The RX/TX pins on the Prop Plug will plug in to the DE0 board directly. So without any additional wires, anyone with a DE0 and a Prop Plug can at least run the monitor. Just follow ctwardell's diagram for matching up the RX/TX pins. No need to plug in GND/RST.
I'm using:
- DE0 Nano
- add-on board.
[FONT=Arial, Tahoma, Verdana, Geneva, sans-serif]- Prop Plug [/FONT]
[FONT=Arial, Tahoma, Verdana, Geneva, sans-serif]Is their anything special required to get the monitor to work with this version?[/FONT]
[FONT=Arial, Tahoma, Verdana, Geneva, sans-serif]Everything else seems to work but I don't get any response from the monitor. I remember that I had to remove the memory chip in a earlier version to get it to work but that's been corrected in this version .[/FONT]
I've got the same configuration. I never put my memory chip back in. I can try it with the chip later tonight to see if/how it works.
re:I've got the same configuration. I never put my memory chip back in. I can try it with the chip later tonight to see if/how it works.
I haven't put the chip back in mine either, not yet.. Does it currently work with the chip out?
Hi Bob
I have a DE0 with the latest build (feb 6) + add on board + prop plug and no flash chip installed.
Monitor works fine with PST from 600 baud to 460800 baud.
Cheers
Brian
re:I have a DE0 with the latest build (feb 6) + add on board + prop plug and no flash chip installed.
Ok great!! that's what I needed to know. I'll check the monitor code to see if the pin setup changed.
Bob
There may be a bug in the monitor on the last release. It doesn't process hex that you type. It's something trivial, I'm sure, and the next release will have it fixed. The monitor DOES come up, though.