Aiming for a clean P1V compile? (and anyone added a simple UART?)
Cluso99
Posts: 18,069
Postedit: Change heading
Has anyone added a simple UART to their P1V?
And has anyone done a clean compile of the P1V?
Has anyone added a simple UART to their P1V?
And has anyone done a clean compile of the P1V?
Comments
Not sure what you mean bu a "clean" compile?
Do you mean no warnings in the compilation report?
P.S. Not yet on the UART question.
A UART in COG is regarded by many as a terrible waste of a 32 bit processor and 2K of RAM.
If you can build a P1 for FPGA why not add a little logic for a UART, it's no worse an idea than the Prop having counters or video generators.
In fact arguably the Prop would be better off with having hardware UARTs than video generators.
@Cluso
How are you thinking this should be done?
Should there be one UART per COG in the manner of video hardware? With some special registers in COG space. Perhaps replacing the video registers.
Should there be a UART as a shared HUB resource.
Or instead of using registers would there be UART instructions like the lock instructions?
They were very easy to use and fast!
For the UART, I just want a simple single UART. Not a standard UART with error flags looking like a 16450 style, but like the pair Chip did in the P2.
I intend to remove the Video so I can use those registers for Tx and Rx.
I am going to compile a single cog with the hub available at full cog speed, and available as extended cog ram too. By changing JMPRET and TJ/DJ to relative and making the pc 14 bits (long address) I can execute from extended cog / hub ram.
Hence my need for a simple UART to communicate with th PC.
I haven't had any problems (currently on Quartus II 14.1 for Windows). Because I didn't like timing warnings, I wrote an SDC file for the DE0-Nano (I don't have a DE2-115 and the Cyclone V on the BEMicro CV is tricky) that lets TimeQuest do its thing without warnings. That file is currently pushed to jacgoudsmit's P1V fork (https://github.com/jacgoudsmit/P1V).
What kind of compile errors are you seeing?
Since I am going to be playing around with potential timing problems I want to start with a clean compile.
So thanks... I will download and compile.
These .sdc files are huge. Some hundred lines of code....
True. And it's not very flexible, at least for those who want to add or remove cogs and or counters. Of course, it's all just tcl, so it's possible to write it a bit more generically. But I won't be getting around to that any time soon...
I wonder how hard it would be to extend the functionality of the various registers to use it as a proper UART. After all, there are quite a number of unused bits in the video configuration registers...
===Jac
We have used the VGA to send out clocked serial databits in the P1. It would have been nice to be able to input them serially too. It probably wasn't on Chip's mind when he designed the VGA.
IIRC the video used quite a bit of the fpga, hence I cut down the VGA to only 1 or 2 cogs. I would think in reality we could set cogs say cogs 0 & 4 to have VGA, and cogs 1,2,3,5,6,7 to have UARTs. Then these cogs have access to the VGA registers and WaitVID instruction for UART registers and instructions.
Jac,
I downloaded the clean master from git. Nice job. It still reports 36 warnings although I think most are not relevant.
I presume the top.tdf is the place to change to increase the clock...
pll : altpll with ( pll_type = "enhanced", operation_mode = "normal", inclk0_input_frequency = 20000, -- 20000ps = 50MHz clk0_multiply_by = 16, clk0_divide_by = 5);I would like to try 96MHz (USB) and above. Anyway,I will just give it a try.I've been thinking something similar Jac. You could use FRQA/B to set the baud rate, and PHSA/B to read or write UART data. The CTRA/B config register, upon read, could identify how many bytes are in the RX buffer. The buffers themselves can be hidden behind the PHSA/B registers and be of the required depth.
Hopefully its just a matter of substituting cog_ctra and cog_vid_. We could make other peripherals in a similar way too, it would make them easy to substitute.
I've been thinking of changing the video Verilog to reduce the video hardware too, but I would probably implement some sort of automatic allocation mechanism, linked to write-operations to any video register. Whichever cog is the first to write to any of the video registers, gets the video; when the cog stops, the video hardware is "freed" again. That way most existing SPIN/PASM software will still be compatible (as long as you don't run too many video cogs obviously). The allocation would need 8-to-1 multiplexers for each video register of course, and I don't know what the consequences would be for LE usage.
Another option is to redesign the video hardware so that each pin group (0-7, 8-15, 16-23 and 24-31) has its own video hardware, instead of assigning video hardware to the cogs. This should save at least half of the video hardware but might be tricky to implement, in case of conflicts between cogs that are trying to control the same pin group.
Thanks! I didn't make any changes to the code in my P1V github repo, I just reorganized it so that it would take less work to implement changes and port them between targets. The warnings are probably the same (timing) warnings of the original code. I've only done minimal testing because I didn't have a lab to hook up my BeMicro CV to anything worth really running an application.
I've been working on other projects and I moved from Arizona to California last month, so I haven't had much time for P1V...
===Jac
By adding the files "top.tdf", "tim.tdf", "dig.v" to the project in Quartus removes 3 warnings.
Project/Add Files/Files/Add (top.tdf, tim.tdf, dig.v)
There must be a way to have these files included in the project without the need to modify the project in Quartus.
Does anyone know how to solve this ???
Here are the changes to hub_mem.v to remove 2 warnings (add the `ifndef... and `endif lines)
// 4096 x 32 rom containing character definitions ($8000..$BFFF) `ifndef DISABLE_FONT_ROM (* ram_init_file = "hub_rom_low.hex" *) reg [31:0] rom_low [4095:0]; reg [31:0] rom_low_q; always @(posedge clk_cog) if (ena_bus && a[13:12] == 2'b10) rom_low_q <= rom_low[a[11:0]]; `endifHere are the remaining 11 warnings (note the hub_mem.v line number is incorrect)
Warning (276027): Inferred dual-clock RAM node "dig:core|cog:coggen[0].cog_|cog_ram:cog_ram_|altsyncram:r[0][31]__1" from synchronous design logic. The read-during-write behavior of a dual-clock RAM is undefined and may not match the behavior of the original design. Warning (10858): Verilog HDL warning at hub_mem.v(102): object rom_high used but never assigned Warning (19016): Clock multiplexers are found and protected Warning (19017): Found clock multiplexer dig:core|cog:coggen[7].cog_|cog_ctr:cog_ctra|Mux6 Warning (19017): Found clock multiplexer dig:core|cog:coggen[6].cog_|cog_ctr:cog_ctra|Mux6 Warning (19017): Found clock multiplexer dig:core|cog:coggen[5].cog_|cog_ctr:cog_ctra|Mux6 Warning (19017): Found clock multiplexer dig:core|cog:coggen[4].cog_|cog_ctr:cog_ctra|Mux6 Warning (19017): Found clock multiplexer dig:core|cog:coggen[3].cog_|cog_ctr:cog_ctra|Mux6 Warning (19017): Found clock multiplexer dig:core|cog:coggen[2].cog_|cog_ctr:cog_ctra|Mux6 Warning (19017): Found clock multiplexer dig:core|cog:coggen[1].cog_|cog_ctr:cog_ctra|Mux6 Warning (19017): Found clock multiplexer dig:core|cog:coggen[0].cog_|cog_ctr:cog_ctra|Mux6 Warning (19016): Clock multiplexers are found and protected Warning (19017): Found clock multiplexer tim:clkgen|clk_pll~2 Warning (276020): Inferred RAM node "dig:core|hub:hub_|hub_mem:hub_mem_|ram3_rtl_0" from synchronous design logic. Pass-through logic has been added to match the read-during-write behavior of the original design. Warning (276020): Inferred RAM node "dig:core|hub:hub_|hub_mem:hub_mem_|ram2_rtl_0" from synchronous design logic. Pass-through logic has been added to match the read-during-write behavior of the original design. Warning (276020): Inferred RAM node "dig:core|hub:hub_|hub_mem:hub_mem_|ram1_rtl_0" from synchronous design logic. Pass-through logic has been added to match the read-during-write behavior of the original design. Warning (276020): Inferred RAM node "dig:core|hub:hub_|hub_mem:hub_mem_|ram0_rtl_0" from synchronous design logic. Pass-through logic has been added to match the read-during-write behavior of the original design. Warning (292013): Feature LogicLock is only available with a valid subscription license. You can purchase a software subscription to gain full access to this feature. Warning (15714): Some pins have incomplete I/O assignments. Refer to the I/O Assignment Warnings report for details Warning (169177): 34 pins must meet Altera requirements for 3.3-, 3.0-, and 2.5-V interfaces. For more information, refer to AN 447: Interfacing Cyclone IV E Devices with 3.3/3.0/2.5-V LVTTL/LVCMOS I/O Systems. Info (169178): Pin io[0] uses I/O standard 3.3-V LVCMOS at J14 Info (169178): Pin io[1] uses I/O standard 3.3-V LVCMOS at J13 Info (169178): Pin io[2] uses I/O standard 3.3-V LVCMOS at K15 Info (169178): Pin io[3] uses I/O standard 3.3-V LVCMOS at J16 Info (169178): Pin io[4] uses I/O standard 3.3-V LVCMOS at L13 Info (169178): Pin io[5] uses I/O standard 3.3-V LVCMOS at M10 Info (169178): Pin io[6] uses I/O standard 3.3-V LVCMOS at N14 Info (169178): Pin io[7] uses I/O standard 3.3-V LVCMOS at L14 Info (169178): Pin io[8] uses I/O standard 3.3-V LVCMOS at P14 Info (169178): Pin io[9] uses I/O standard 3.3-V LVCMOS at N15 Info (169178): Pin io[10] uses I/O standard 3.3-V LVCMOS at N16 Info (169178): Pin io[11] uses I/O standard 3.3-V LVCMOS at R14 Info (169178): Pin io[12] uses I/O standard 3.3-V LVCMOS at P16 Info (169178): Pin io[13] uses I/O standard 3.3-V LVCMOS at P15 Info (169178): Pin io[14] uses I/O standard 3.3-V LVCMOS at L15 Info (169178): Pin io[15] uses I/O standard 3.3-V LVCMOS at R16 Info (169178): Pin io[16] uses I/O standard 3.3-V LVCMOS at K16 Info (169178): Pin io[17] uses I/O standard 3.3-V LVCMOS at L16 Info (169178): Pin io[18] uses I/O standard 3.3-V LVCMOS at N11 Info (169178): Pin io[19] uses I/O standard 3.3-V LVCMOS at N9 Info (169178): Pin io[20] uses I/O standard 3.3-V LVCMOS at P9 Info (169178): Pin io[21] uses I/O standard 3.3-V LVCMOS at N12 Info (169178): Pin io[22] uses I/O standard 3.3-V LVCMOS at R10 Info (169178): Pin io[23] uses I/O standard 3.3-V LVCMOS at P11 Info (169178): Pin io[24] uses I/O standard 3.3-V LVCMOS at R11 Info (169178): Pin io[25] uses I/O standard 3.3-V LVCMOS at T10 Info (169178): Pin io[26] uses I/O standard 3.3-V LVCMOS at T11 Info (169178): Pin io[27] uses I/O standard 3.3-V LVCMOS at R12 Info (169178): Pin io[28] uses I/O standard 3.3-V LVCMOS at T12 Info (169178): Pin io[29] uses I/O standard 3.3-V LVCMOS at R13 Info (169178): Pin io[30] uses I/O standard 3.3-V LVCMOS at B11 Info (169178): Pin io[31] uses I/O standard 3.3-V LVCMOS at E10 Info (169178): Pin inp_resn uses I/O standard 3.3-V LVCMOS at D9 Info (169178): Pin clock_50 uses I/O standard 3.3-V LVCMOS at R8Does anyone know how to remove any of these warnings ???set_global_assignment -name VERILOG_FILE dig.v set_global_assignment -name AHDL_FILE tim.tdf set_global_assignment -name AHDL_FILE top.tdfto the filesBeMicroCV.qsf
DE0-Nano.qsf
DE2-115.qsf
after these line(s)
set_global_assignment -name FMAX_REQUIREMENT "80 MHz" -section_id clock_cog set_global_assignment -name FMAX_REQUIREMENT "160 MHz" -section_id clock_pll set_global_assignment -name VERILOG_MACRO "DISABLE_FONT_ROM=1"and the fix above, we are now down to 0/11 warnings without the need to add files to the project.It took 16m33s - ugh!
There were 6 errors and 17 warnings.
2 errors complained about a missing BeMicroCV.sdc file and 4 errors were timing errors.
Can I just copy the DE0-Nano.sdc file???
Here are the errors and warnings
Warning (19016): Clock multiplexers are found and protected Warning (19017): Found clock multiplexer tim:clkgen|clk_pll~2 Warning (113007): Byte addressed memory initialization file "hub_rom_low_b3.hex" was read in the word-addressed format Warning (113007): Byte addressed memory initialization file "hub_rom_low_b2.hex" was read in the word-addressed format Warning (113007): Byte addressed memory initialization file "hub_rom_low_b1.hex" was read in the word-addressed format Warning (113007): Byte addressed memory initialization file "hub_rom_low_b0.hex" was read in the word-addressed format Warning (113007): Byte addressed memory initialization file "hub_rom_high_unscrambled_b3.hex" was read in the word-addressed format Warning (113007): Byte addressed memory initialization file "hub_rom_high_unscrambled_b2.hex" was read in the word-addressed format Warning (113007): Byte addressed memory initialization file "hub_rom_high_unscrambled_b1.hex" was read in the word-addressed format Warning (113007): Byte addressed memory initialization file "hub_rom_high_unscrambled_b0.hex" was read in the word-addressed format Warning (13024): Output pins are stuck at VCC or GND Warning (13410): Pin "ledg[1]" is stuck at GND Warning (13410): Pin "ledg[2]" is stuck at GND Warning (13410): Pin "ledg[3]" is stuck at GND Warning (13410): Pin "ledg[4]" is stuck at GND Warning (13410): Pin "ledg[5]" is stuck at GND Warning (13410): Pin "ledg[6]" is stuck at GND Warning (13410): Pin "ledg[7]" is stuck at GND Warning: RST port on the PLL is not properly connected on instance altpll:pll|altpll_0cp:auto_generated|generic_pll1. The reset port on the PLL should be connected. If the PLL loses lock for any reason, you might need to manually reset the PLL in order to re-establish lock to the reference clock. Info: Must be connected Warning: RST port on the PLL is not properly connected on instance altpll:pll|altpll_0cp:auto_generated|generic_pll1. The reset port on the PLL should be connected. If the PLL loses lock for any reason, you might need to manually reset the PLL in order to re-establish lock to the reference clock. Info: Must be connected Warning (21300): LOCKED port on the PLL is not properly connected on instance "altpll:pll|altpll_0cp:auto_generated|generic_pll1". The LOCKED port on the PLL should be connected when the FBOUTCLK port is connected. Although it is unnecessary to connect the LOCKED signal, any logic driven off of an output clock of the PLL will not know when the PLL is locked and ready. Warning (292013): Feature LogicLock is only available with a valid subscription license. You can purchase a software subscription to gain full access to this feature. Warning (15714): Some pins have incomplete I/O assignments. Refer to the I/O Assignment Warnings report for details Warning (177007): PLL(s) placed in location FRACTIONALPLL_X54_Y38_N0 do not have a PLL clock to compensate specified - the Fitter will attempt to compensate all PLL clocks Info (177008): PLL altpll:pll|altpll_0cp:auto_generated|generic_pll1~FRACTIONAL_PLL Critical Warning (332012): Synopsys Design Constraints File file not found: 'BeMicroCV.sdc'. A Synopsys Design Constraints File is required by the TimeQuest Timing Analyzer to get proper timing constraints. Without it, the Compiler will not properly optimize the design. Critical Warning (332012): Synopsys Design Constraints File file not found: 'BeMicroCV.sdc'. A Synopsys Design Constraints File is required by the TimeQuest Timing Analyzer to get proper timing constraints. Without it, the Compiler will not properly optimize the design. Critical Warning (332148): Timing requirements not met Info (11105): For recommendations on closing timing, run Report Timing Closure Recommendations in the TimeQuest Timing Analyzer. Critical Warning (332148): Timing requirements not met Info (11105): For recommendations on closing timing, run Report Timing Closure Recommendations in the TimeQuest Timing Analyzer. Critical Warning (332148): Timing requirements not met Info (11105): For recommendations on closing timing, run Report Timing Closure Recommendations in the TimeQuest Timing Analyzer. Critical Warning (332148): Timing requirements not met Info (11105): For recommendations on closing timing, run Report Timing Closure Recommendations in the TimeQuest Timing Analyzer.Unfortunately, no. Cyclone IV and Cyclone V have very different PLL declarations.
It is not the fastest as it is both Rx and Tx, but it may be of use as it is a complete Verilog module with a Github repository.
http://opencores.org/project,osdvu
And here is a link to another coder with explanation.
http://www.fpga4fun.com/SerialInterface5.html
And a TX only configuration.
http://ece301.com/fpga-projects/52-uart-txd.html
And a RX only configuration to mate with the above TX only
http://ece301.com/fpga-projects/57-uart-rxd.html
I haven't yet tried any as I am awaiting the arrival of my first FPGA devices. But I also tend to feel that using a whole cog for serial i/o may be a bit wasteful. These may allow one to get an 'outside' UART.
He has done an excellent job of integrating the Verilog code for all the various Altera Development boards -- Terrasic or BeMIcro.
https://github.com/jacgoudsmit/P1V
thanks... jac
You really seem to have mastered Quartus II and the P1V. We can all learn something from this repository.
Thanks for your kind words, but at this time I know barely enough of Verilog and Quartus to be dangerous. And I don't know hardly anything about the Xilinx ISE tools because I don't own any Xilinx hardware (yet).
I don't know if a clean compile of P1V will ever be possible; Quartus is very picky (which is a good thing!) and it looks like it's simply impossible to do some things without generating warnings. And I could use any help I can get!
===Jac
Maybe not absolutely clean. But all the code that Parallax links to is older, and their .zip that includes the BeMicroCV doesn't work.
You are still way ahead of me as I just got started with Quartus II, Verilog, and VHDL. At the very least, I don't have to bother with soldering to build something sophisticated.
In the propeller world, you would build the uarts in cogs in software. But in the vhdl world, a uart is a component that is easy to drop into the code, and easy to add more with just a few lines of vhdl each time, so it makes more sense to add vhdl, and to keep cogs free for other more complex and flexible tasks.
In the strange hybrid world of a propeller emulated on a fpga, well, anything goes, and it may well be better to add things in vhdl - eg SPI, vga drivers, external memory management units, external memory, and still have 8 cogs free.