Must be a compiler setting then as the version of the project you uploaded compiles withexactlyalmost the same Fmax results as you're getting. How odd - I was sure I hadn't changed anything but the results speak for themselves.
EDIT:
I'm getting clk[0] Fmax = 125.94 MHz, clk[2] Fmax = 130.72 MHz. Not quite the same as what you're getting. Is that usual or is the Fmax sensitive to the host computer the project is compiled on?
//************************************************************************************************************************************************
// p_blit_features bitmask features:
// 0 = Enable blitter 1 = run biltter copying source to output coordinates, 0 = Simple pixel write command
// 1 = Enable paste mask 1 = Pasting pixels with transparency mask, 0 = Always paste pixels even if the source has the selected transparent color
// 2 = Enable center paste 1 = Offset the paste up and to the left by half of blit_width/height, 0 = Use the paste coordinates as the top-left
//************************************************************************************************************************************************
Drawing random filled/frame rectangles shows up a strange error in their rendering too:
Initial testing is throwing up a problem. I'm using the identical test that I've been using for the last couple of weeks.
Looks like the bottom line of the filled rectangle isn't getting drawn and there's an issue with certain orders of triangles?
Line renderer seems to be working:
Only proceed onto the this code once you fully verify the previous code.
Well too late. I need to see why you are getting those errors.
Just ry this code, without using the blitter, the errors will probably be identical.
Yup, the new version only adds the blitter. No other changes.
I need to sleep now. I'll look at the bugs tonight.
For now, you can start playing with the blitter using simple plot pixel and line commands.
Yup, the new version only adds the blitter. No other changes.
I need to sleep now. I'll look at the bugs tonight.
For now, you can start playing with the blitter using simple plot pixel and line commands.
I'll make a start looking at the blitter commands and see if I can get some text on screen with the graphics, but I'll document the new commands first. Oh, one other thing I noticed - Fmax is down to 119.77 MHz.
Were the timing analyzer results clock result red?
Did the compiler say that timing constraints were not me?
Was that 119.77MHz limit result for CLK[0], the one which needs to be at least 125MHz?
Or was that CLK[2], your PS2 keyboard clock which is only running at 50MHz where the 119.77MHz limit is actually 2x fine?
Remember, I fixed all the IO and core timing constraints, if the compiler doesn't make that section 'RED', then everything is ok.
Your FPGA is 90% full, squeezing in any more logic and trying to maintain CLK[0]'s 125MHz minimum means other slower sections will begin to loose placement and routing priority dropping their top FMAX is there is clearance to do so.
Were the timing analyzer results clock result red?
Did the compiler say that timing constraints were not me?
Was that 119.77MHz limit result for CLK[0], the one which needs to be at least 125MHz?
Or was that CLK[2], your PS2 keyboard clock which is only running at 50MHz where the 119.77MHz limit is actually 2x fine?
Remember, I fixed all the IO and core timing constraints, if the compiler doesn't make that section 'RED', then everything is ok.
Uh, never mind, I'm having a bad day. It was for clk[2], not clk[0].
I've had a little free time to try and get a character to blit onto the screen, but having mixed results because I'm clearly making a mistake in setting the base source address or the offset or something.
What I'm trying to do to test the blitter is this:
1. Set the base memory address to the start of the font table (0x0200)2. Set the source raster width to 8 pixels with 1-bit colour depth
- Send 0x200 to X[0] - command 0x8200
- Send 0x00 to Y[0] - command 0xC000
- Set base memory address - command 0x7800
3. Set blitter width/height to 8x16
- Set Y[2] to 8 - command 0xE008
- Set raster width to Y[2] pixels and bpp to 1 - command 0x7200
4. Set source offset to 16xASCII char # - in this case, capital 'X' (0x58 x 0x10 = 0x580)
- Set X[2] to 7 - command 0xA007
- Set Y[2] to 15 - command 0xE00F
- Set copy width/height - command 0x7400
5. Turn on the blitter, with Paste Mask and Centre Paste turned off
- Set X[2] to 0 - command 0xA000
- Set Y[2] to 0x580 - command 0xE580
- Set source image offset - command 0x7600
6. Blit the character 'X' to 100,100 on the screen
- Enable blitter, disable PM + CP - command 0x0001
- Set X[0] to 100 - command 0x8064
- Set Y[0] to 100 - command 0xC064
- Plot a pixel in yellow (colour 0x0E) - command 0x010E
The output I get is this:
(Attachment Link)
Two things are immediately obvious - it's not a capital X and there's a pixel missing at the very end. I'd hesitate to call either of these an issue with the blitter just yet as I'm not 100% confident I'm setting it up properly, hence the rambling list above of commands I'm using to get this output.
EDIT: Definitely something wrong with my base memory and offset address setup. I'm getting the letter 'j' appear in 1-bit mode.
Your FPGA is 90% full, squeezing in any more logic and trying to maintain CLK[0]'s 125MHz minimum means other slower sections will begin to loose placement and routing priority dropping their top FMAX is there is clearance to do so.
I'm working on the schematics for the EP4CE22F17 version currently, after getting a little scared off by the potential power supply requirements for the Cyclone V and lack of reference designs anywhere I can make use of.
The only hints of schematics I've found use QFN power chips, which means there's more of a learning curve for me than just trying to solder a BGA, coupled with the extra power draw that my existing power board in my uCOM just won't keep up with - so I'd have to re-design and up-rate the power card first. Seems the EP4CE22 should be okay though, and I have reference schematics I can use to confirm my design with. I need some time to be able to make headway on its design though.
Something weird is going on, it may be the pixel address generator.
It's also yellow?
The last pixel also looks missing. OK, I see the bug. Will fix tonight.
Try Character 01, IE offset Y=16. This should generate the VGA font's happy face.
PAGET and Pixel Writer has never been tested with reading 1 bit color under strict scrutiny.
Or something's overwritten your font.
But, Yellow? Unless you used a weird write paste color, maybe the Pixel Writer needs to be checked.
Try making the base address the screen memory, and raster width of 320 and match the 4 bit color.
Then copy, after painting your other test triangle and blue box.
Make copy blit width & height 160x200 and paste blit at 160,0. A copy of the left half of the screen should appear on the right hand side.
Need to do a full sim tonight...
Arrrg, so many setup variables...
Except for the last missing pixel, the Blitter inside the geometry unit is generating the correct commands and read and write coordinates which are being sent to the address generator. I need to see what's happening after inside the address generator. The originally, the pixel writer did perform correct reads and writer when I did a simulation of it. And, it could not draw proper geometry shapes on a 16 color screen if it weren't first reading GPU ram, then editing the correct bit mask, then doing a pixel write. And the current screen copy shows a 0 color transform, going from 16 color to 16 color screen.
The destination being in the right screen location, but with stretched line images, I would bet the address generator isn't generating the right read address. Probably a typo somewhere as the read address generation mirrors the write address which we knows it works.
Schematic 1.
https://software.intel.com/content/www/us/en/develop/articles/de10-nano-board-schematic.html
Another:
https://www.analog.com/media/en/technical-documentation/eval-board-schematic/c5_soc_devkit_c.pdf
Search for libraries.
For switching regulator DC-DC converters, try this guy: AOZ1284.
It's cheap and only requires an external 10uH SMD power inductor and 1 diode with a few resistors and caps.
4 amps output, no heatsink.
Adjustable voltage from 0.8v to beyond 5v.
http://www.aosmd.com/res/data_sheets/AOZ1284PI.pdf
The more expensive 'TLV62130A' @1$ can deliver the same full 3 amp current with a smaller Vin-Vout voltage gap, IE 4.5v to 3.3v.
I think Farnell/RS Components has stock of this one, but they jacked up the price compared to the TI store.
That didn't work as expected. I'm still not 100% sure I'm setting up the blitter properly though. For that last image, I did this:
- Set base memory address to 0x1200 - 0x8200, 0xC001, 0x7800
- Set source raster width to 320 pixels, 4 bpp - not clearing 0xA000 0xE13F, 0x7202
- Set blitter width/heigh to 160x200 - 0xA0A0, 0xE0C8, 0x7400
- Set image offset to 0 - 0xA000, 0xE000, 0x7600
- Blit - 0x80A0, 0xC000, 0x010E
So which is better - the TLV62130A or the AOZ1284? I'd be using them to provide a 5V and 3.3V rail to the entire uCOM system, as well as the GPU - which would have more chips supplying the 1.2 and 2.5V rails from the 5V rail. The uCOM draws about 120mA without the GPU.
That didn't work as expected. I'm still not 100% sure I'm setting up the blitter properly though. For that last image, I did this:
- Set base memory address to 0x1200 - 0x8200, 0xC001, 0x7800
- Set source raster width to 320 pixels, 4 bpp - not clearing 0xA000 0xE13F, 0x7202
- Set blitter width/heigh to 160x200 - 0xA0A0, 0xE0C8, 0x7400
- Set image offset to 0 - 0xA000, 0xE000, 0x7600
- Blit - 0x80A0, 0xC000, 0x010E
4bpp is 0x7203, the screen width is larger than 12 bits.
And, 0xAxxx and 0xExxx, if I am not mistaken, you have the width set to $13F000? 1306624 X pixels?
Shouldn't it be $000140? X=320 pixels? this explains some of the mess.
Ok, the 'ONE' fix in this code is just the missing last pixel.
I need to see blitts with the right settings before I go messing around in the pixel writer.
I'm working on the sorted coordinates and 'Filled' polygons now.
That didn't work as expected. I'm still not 100% sure I'm setting up the blitter properly though. For that last image, I did this:
- Set base memory address to 0x1200 - 0x8200, 0xC001, 0x7800
- Set source raster width to 320 pixels, 4 bpp - not clearing 0xA000 0xE13F, 0x7202
- Set blitter width/heigh to 160x200 - 0xA0A0, 0xE0C8, 0x7400
- Set image offset to 0 - 0xA000, 0xE000, 0x7600
- Blit - 0x80A0, 0xC000, 0x010E
4bpp is 0x7203, the screen width is larger than 12 bits.
Hmm.. I need to clarify this setting then, as the only notes I have pertain to the MAGGIE settings in the hardware registers, where bits 2-0 of the BP2RAST_cmd are:
Bit 2 Bit 1 Bit 0 Video Mode
0 0 0 1-bit colour
0 0 1 2-bit colour
0 1 0 4-bit colour
0 1 1 8-bit colour
1 0 0 16-bit, 8 pixels-per-word
1 0 1 16-bit, 4 pixels-per-word
1 1 0 16-bit, 2 pixels-per-word
1 1 1 16-bit, true colour
I've been using these to set the bpp for the geo unit previously. 0x7203 should be 8-bit colour if I'm using the right table?And, 0xAxxx and 0xExxx, if I am not mistaken, you have the width set to $13F000? 1306624 X pixels?
Shouldn't it be $000140? X=320 pixels? this explains some of the mess.
I knew in my bones I'd made some mistakes. I've spotted some more too (like not setting destination raster width for the letter blit, or the source raster width for the half-screen blit. I blame my lack of concentration and being in the early stages of a cold.Ok, the 'ONE' fix in this code is just the missing last pixel.
I need to see blitts with the right settings before I go messing around in the pixel writer.
I'm working on the sorted coordinates and 'Filled' polygons now.
Here's the latest image, with the updates mentioned above.
[ Attachment Invalid Or Does Not Exist ]
Blitter is being enabled with 0x0001, and both blits are being done with 0x010E commands.
Maggie settings are different from the geometry settings, remember...
For setting up the geometry controls, the bit depth is number of bits per pixel -1. Not the table you provided.
I would like to see the text working....
Try character 0 and character 1, that would be a blank square and the happy face...