Add initial support for Olimex iCE40HX8K-EVB #24
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Builds but does not work on actual hardware. Perhaps due to something with the bram?
Generated files should be kept out of source control (unless they are lengthy or difficult to create).
These are necessary when building with a toolchain that supports both riscv32 and riscv64.
|
wow! thank you for the contribution! I have some suggestions in order to try make the darkriscv work in the iCE40HX8K:
As long you ensure that the CLK and RES are present, maybe is possible check about the UART. The following change will make the UART print the character 'A' regardless the core is working or not (in fact, case the core is running, it will be locked in the putchar function, as long the UART is busy printing 'A'): index fe63ff6..67bdb31 100644
--- a/rtl/darkuart.v
+++ b/rtl/darkuart.v
@@ -96,8 +96,8 @@ module darkuart
reg UART_IREQ = 0; // UART interrupt req
reg UART_IACK = 0; // UART interrupt ack
- reg [ 7:0] UART_XFIFO = 0; // UART TX FIFO
- reg UART_XREQ = 0; // xmit request (core side)
+ reg [ 7:0] UART_XFIFO = "A"; // UART TX FIFO
+ reg UART_XREQ = 1; // xmit request (core side)
reg UART_XACK = 0; // xmit ack (uart side)
reg [15:0] UART_XBAUD = 0; // baud rate counter
reg [ 3:0] UART_XSTATE= 0; // idle state
@@ -124,7 +124,7 @@ module darkuart
begin
if(BE[1])
begin
- UART_XFIFO <= DATAI[15:8];
+ UART_XFIFO <= "B"; // DATAI[15:8];
`ifdef SIMULATION
// print the UART output to console! :)
if(DATAI[15:8]!=13) // remove the '\r'
@@ -144,7 +144,7 @@ module darkuart
$finish();
end
`else
- UART_XREQ <= !UART_XACK; // activate UART!
+ //UART_XREQ <= !UART_XACK; // activate UART!
`endif
end
//if(BE[2]) UART_TIMER[ 7:0] <= DATAI[23:16];
@@ -179,7 +179,7 @@ module darkuart
UART_XSTATE==`UART_STATE_IDLE ? UART_XSTATE+(UART_XREQ^UART_XACK) :
UART_XSTATE+(UART_XBAUD==0);
- UART_XACK <= RES||UART_XSTATE==`UART_STATE_ACK ? UART_XREQ : UART_XACK;
+ //UART_XACK <= RES||UART_XSTATE==`UART_STATE_ACK ? UART_XREQ : UART_XACK;
end
assign TXD = UART_XSTATE[3] ? UART_XFIFO[UART_XSTATE[2:0]] : UART_XSTATE==`UART_STATE_START ? 0 : 1;Of course, the simulation will not work with this change (the simulation does not really foreseen the UART printing at 115200 bps in order to run faster). |
|
Another interesting suggestion is loopback the RX and TX in the FPGA to make sure that the UART is correct wired. A small project to test the clock generator to blink a LED at the rate of 1Hz, the reset wired to another LED and loopback the TX/RX may help make sure that the top level is correct wired, clocked and out of reset. Of course, although the darkriscv worked fine with a small set of different tools (Xilinx ISE, Xilinx Vivado, Icarus Verilog and some reports about Multisim), there is the possibility that the code does not work well with a different set of tools due to syntax tricks that are optimized to infer the correct logic in Xilinx tools. In fact, I am very curious about the synthesis results from Yosis: how many LUTs are required in the synthesis? how about the maximum frequency? |
This works fine.
I'm not so sure how I can check this.
I do get an A character, but it comes very slowly (once every few seconds, but occasionally many at once).
Here is the output of nextpnr when built with |
|
This is a good news, because the 'A' in the output means that the clock is working as expected, since the UART is working with the correct baud rate, and that the reset is working as expected, since the UART state machine uses the RES signal. As long there are no '\n' in the stream, the terminal is probably buffering the 'A' stream, but this is observable in the Icarus simulation too. About the synthesis output, I guess the synthesis requires 2210LUTs and it appears to be very consistent with the RV32E in the Spartan-3E, which takes about 1800LUTs without threading. The MAC instruction uses a special DSP48 block in the Xilinx FPGAs, but it is not mandatory and can be disabled for sure. The threading requires more LUTs, in a way that the RV32E without threading appears to fit better in FPGAs w/ LUT4 technology. As long the clock, reset and UART appears to work well, another suggestion in order to debug the design is double-check about the ROM and RAM loading. In the case of Xilinx tools there are lots of messages regarding the ROM and RAM loading, in a way that sometimes the memories are not correctly loaded. Case the ROM and RAM are correctly loaded, maybe test w/ the 2-stage pipeline version is a good thing, as long the memories are wired in a different way. One interesting way to debug the ROM content is create some comparators with the IDATA and IADDR to trigger some LEDs when specific patterns are detected. For example, as long the first instruction in the ROM is 0x00001737 and the second is 0x00472783, it is possible compare the IDATA and activate separate LEDs regarding that instructions, something like this: Case the LEDs never activate, for sure there is something wrong with the ROM. In the case of Xilinx tools, the ROM is typically inferred as a synchronous BlockRAM with registered output, but I am not sure about the behaviour of tools from other manufacturers. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This code currently builds but does not work on real hardware. I have had best results with
PNR=nextpnrandPNRFLAGS=--opt-timing. Clock frequencies listed inconfig.vhare based on timing results from PNR, not from empirical testing. I have been unable to get any output over serial, even with the clock frequency well below timing requirements. I have also tried swapping the TX and RX ports. Please let me know if you have any suggestions for things to try.