Here is the update from the Big Change!!!
cgracey
Posts: 14,151
Here is the update from the Big Change:
=== NEW FILE ON 11/27/2013 ===
Terasic_Prop2_Emulation_2013_11_27.zip
This will work with the DE0-Nano and DE2-115 boards that some of you have, along with the adapter boards we sent out.
A lot of specifics have changed regarding configuration registers. Be sure to review any sections of Prop2_Docs.txt that relate to your programs. There are several demonstration programs in the .zip that generate video. Balls.spin incorporates a callable SDRAM driver that uses the cog's AUX RAM, instead of the QUADs - so it can run on the DE0-Nano.
It's taking me several compiler runs, lately, before I get a fast-enough DE0-Nano compilation out of Quartus II (the Altera FPGA tool). I had to adjust some fitting options before it would even fit, at all. Now a one-cog compilation is taking 99.65% of the DE0-Nano FPGA's logic elements.
Thanks for your patience. Now I'm making some transistor-size changes for Beau to work on...
=== NEW FILE ON 11/27/2013 ===
Terasic_Prop2_Emulation_2013_11_27.zip
This will work with the DE0-Nano and DE2-115 boards that some of you have, along with the adapter boards we sent out.
A lot of specifics have changed regarding configuration registers. Be sure to review any sections of Prop2_Docs.txt that relate to your programs. There are several demonstration programs in the .zip that generate video. Balls.spin incorporates a callable SDRAM driver that uses the cog's AUX RAM, instead of the QUADs - so it can run on the DE0-Nano.
It's taking me several compiler runs, lately, before I get a fast-enough DE0-Nano compilation out of Quartus II (the Altera FPGA tool). I had to adjust some fitting options before it would even fit, at all. Now a one-cog compilation is taking 99.65% of the DE0-Nano FPGA's logic elements.
Thanks for your patience. Now I'm making some transistor-size changes for Beau to work on...
Comments
Does that mean the DE0-Nano now has a different max MHz than DE2-115 ?
What is the newest build's target fMAX for each device ?
Can't wait to jump in.
They are both still good at 80MHz. Quartus reported Fmax values of 74MHz for the DE2-115 compilation and 67MHz for the DE0-Nano compilation, but those are worst-case conditions, which none of us are going to have at our workbenches. Both the 5-cog DE2-115 and 1-cog DE0-Nano are being clocked at 80MHz. I've seen flakey behavior at 80MHz when Quartus reports an Fmax of around 60MHz. For what we are all doing now, this overclocking is not an issue. When we spec the Fmax of the actual chip, it will be based on worst-case simulation, backed up by real device testing.
Now to read the new docs, and re-load my nano and de2-115...
Nice update
Else I'm still not found it ---
But I'm still are missing SERTEST --- check if character waiting?
Use 'SERINA D WC' or SERINB D WC'. They will release immediately (1-clock) and if C=1 afterwards, then D is holding what came in.
Thanks
Nico Hattink
In balls.spin, if you change that one pushbutton symbol to 31 for the DE2-115, you can use the left-most pushbutton to freeze the animation. I was just playing around with the new pixel-blending instructions when I made that program, based on the prior color swirler. Roy Eltham taught me the sum-of-products equation that does all the pixel-level effects. It's pretty simple stuff, but when applied it gives very natural, quite photographic effects. By adding some noise from GETLFSR to the balls' colors, then blending towards white, you can plainly see the rough surface of the balls as the light reflects off them. You need to freeze the animation to observe this most clearly, though. It looks like a photograph, to me, and was it all quite accidental.
Thank you very much.
Seriously. What great timing!!
I love the 99.65% aspect. May as well get full value out of the little thing.
Ken Gracey
Good idea.
When Chip heads home, he could maybe run a Quartus build on the New BeMicro CV = Cyclone V (5CEFA2F23C8N), to see what numbers that gives.
This was showing at $42 @ Verical, but seems to be cleaned out at the moment.
add: and this was mentioned too
http://www.altera.com/products/devkits/altera/kit-terasic-cyclone-v-gx-starter.html
Cyclone V GX 5CGXFC5C6F27C7N ( shows stock (2013-12-27) )
Maybe 3 COGs ?
I tried to take one, but the camera just saturated the red, green, and blue, and it didn't do it justice, at all. What we need, somehow, is an actual 24bpp image made into a .bmp.
nutson, thanks for sharing a pic
Can't wait to see the demo Chip!
PS, Chip, I'll let you know if the update works.
Cheers,
Jim.
(Unless it's intended for TV resolution)
What we need to do is stream the pixels out to the SDRAM or something for a frame capture. Like JTCook did on HYDRA for VGA back in the day.
Those balls look amazing (thanks for the pic nutson)
Looks like us DE0 users will be getting a reduced cog implementation shortly
What can be left out???
BTW I noticed in the docs...
COGNEW D, S/#
you say S is only 17 bits and is stored in PTRA. Couldn't/isn't this a full 32 bits?
Seems to imply port pins 92..95 are not internally connected like 96..127. Is this correct?
Nice detail.
Where does this leave details on other serial support like SPI/QSPI/I2S etc, and P2 Counter documentation ?
Is this a final pass, or an interim one, with Serial to come ?
Counter docs would allow some field testing and mode coverage checking.
I used the SEROUTA instruction to send the data back to the PC via the PropPlug, and had the PNut.exe program capture it to a bitmap, which got saved into a file:
At first, I was having all kinds of problems. It turns out that the FTDI driver doesn't receive 2M baud correctly. I had to switch down to 1M baud.
The FTDI parts can loop-back at 2MBd, but they are adding extra stop bits at those high baud rates, so sustained send from something like a P2 into a FS FTDI, is tougher, and will likely have issues, as you found.
How many stop bits did you use ?
Be interesting to see how a FT232H/FT2232H copes with sustained sending at even higher baud speeds.
(and even in Fast Serial mode, which claims <= 50MHz bit rates, but that needs a CLK from P2 => 'clocked async' )
PTRA and PTRB are both 17 bits. So, even though you can express 32 bits in S, after it gets written into PTRA, it's only 17 bits. I used to have PTRA and PTRB at 32 bits, even though only the 17 bottom bits were used (max hub address of $1FFFF), but it was a critical path that stuck out like a sore thumb, as PTRx addressing has to get resolved in a fraction of a cycle.
Pins 92..95 don't do anything and read '0'. We could make them read something else, of course. Pins 96..127 are the inter-cog I/O's which also connect to ALL the peripherals, so they are available for all kinds of applications inside the chip.
The SERA/SERB do just 1 stop bit. That explains the problem I was having. I never thought 1 wouldn't be enough for some receiver. I could add an extra stop bit, but I'm out of config bits now. Also, I haven't gotten into what the SERDES is going to do, so there will probably be a lot of changes, the stop bit being among the least.
Being able to define stop bits will be useful, but an alternative way to manage that, is to allow a granularity of 1 on bit-length.
Then, users can define any number of stop bits (up to frame max of 32b?) via a small SW overhead.